Couchpotato and Sonarr do a lot! of copying?!

[lixe]

I'm not sure whether this is an issue related to unraid or couchpotato and sonarr. If something get's finished in nzbget it goes like this (for tv and movies): unrar to /downloads/tv/xy/unpack , then copying to /downloads/tv/xy and deleting /downloads/tv/xy/unpack, then copying to /media/tv/xy and deleting /downloads/tv/xy. In total the file gets written 4 times instead of just once and then only moving. downloads and media share is using cache disk, so in the beginning everything is happening there until Mover moves it to the array once a week. I'm using a HDD as cache drive formatted xfs, in case that does matter.

As I said I'm not sure if it's because of some unraid setting or couchpotato and sonarr... I couldn't find a related setting/option in sonarr, and in couchpotato "move" is selected as default file action under settings - renamer.

 

I would be so glad if the file would be written only once, since it takes a lot of time and my system stucks while copying, so for example plex isn't usable...

[trurl]

There is definitely nothing about unRAID that causes this. Except for mover moving things from/to cache to/from array, unRAID never copies or moves anything on its own.

[lixe]

I thought that unRAID maybe is causing this behavior, so that everytime a "moving" process is happening, it does copy and delete instead of just moving. But of course that would be strange.

[trurl]

10 minutes ago, lixe said:

I thought that unRAID maybe is causing this behavior, so that everytime a "moving" process is happening, it does copy and delete instead of just moving. But of course that would be strange.

Well, in general, if something is moved from one disk to another, it always involves copying from source to destination, then deleting from source. When moving on the same disk it just updates the filesystem data that keeps track of which folder the file is in.

 

But, there isn't anything going on in unRAID similar to your idea of 'everytime a "moving" process is happening'. Maybe you have some misconception that unRAID moves things around to balance storage. It doesn't.

 

The only "moving" process is the mover script, which typically only moves things from cache to the parity array. Mover runs on a schedule. You can also make it run by pressing a button in the GUI. The default schedule is for mover to only run once a day in the middle of the night.

 

Other than that, unRAID never moves or copies anything.

 

[lixe]

Ok, I didn't expect unRAID to be responsible that for, but wanted to be sure. Can someone tell me wherever it is possible to change the behavior of couchpotato and sonarr, so the files won't get copied that often?

[tjb_altf4]

This is part of the reason I have a downloads/processing folder on an unassigned drive.
It only goes on the array once post processing is finished.

 

Another solution would be to move your VM/dockers off the cache and onto an unassigned drive (SSD)

[Squid]

6 hours ago, lixe said:

I thought that unRAID maybe is causing this behavior, so that everytime a "moving" process is happening, it does copy and delete instead of just moving. But of course that would be strange.

 

6 hours ago, lixe said:

unrar to /downloads/tv/xy/unpack , then copying to /downloads/tv/xy and deleting /downloads/tv/xy/unpack

This will be purely CP.  It's probably doing that in case something goes wrong.

 

6 hours ago, lixe said:

then copying to /media/tv/xy and deleting /downloads/tv/xy

This can never be done as a simple "move" operation, but has to be done as a copy / delete.  unRaid works the same as any other OS.  If the source and destination are not on the same mount points, it has no choice but to do that, as the system has no idea if the mounts are actually on the same physical device.  In this case, your mount points are /media and /downloads

[lixe]

6 hours ago, tjb_altf4 said:

This is part of the reason I have a downloads/processing folder on an unassigned drive.
It only goes on the array once post processing is finished.

 

Another solution would be to move your VM/dockers off the cache and onto an unassigned drive (SSD)

I will try that! Which filesystem should I use for the unassigned drive and how can I do it on unraid? (ssh terminal I guess?)

 

6 hours ago, Squid said:

 

This will be purely CP.  It's probably doing that in case something goes wrong.

 

This can never be done as a simple "move" operation, but has to be done as a copy / delete.  unRaid works the same as any other OS.  If the source and destination are not on the same mount points, it has no choice but to do that, as the system has no idea if the mounts are actually on the same physical device.  In this case, your mount points are /media and /downloads

Thanks for the explanation, makes total sense, didn't think about it that way!

[tjb_altf4]

I'm using XFS on unassigned devices.
It was all setup through the Unassigned Devices plugin thought the web gui.

[trurl]

13 hours ago, tjb_altf4 said:

Another solution would be to move your VM/dockers off the cache and onto an unassigned drive (SSD)

This doesn't really buy you anything if your cache is already SSD. Cache thruput is unaffected by parity just like an Unassigned Device is. So, if the docker volumes in question are already mapped to a cached user share, and your cache disk is already SSD, then I wouldn't expect any benefit from moving to an Unassigned Device.

[d2dyno]

I'm seeing similar results with Sonarr and Radarr. If the downloaded file to be processed (let's say /mnt/user/downloads/tv) is already on the array, when Sonarr/Radarr processes those files, it still copies the files instead of moving them. To me that is illogical behaviour. Unless it's moving those files to another drive in the array while processing. But it's all shares, so no reason it couldn't be on the drive it started out on right?

 

Maybe I'll just have to get a bigger cache going, so I only get the bottleneck during the mover scheduled process.