I have tried looking for a solution or answer to this in the forums, but I think my search kung fu is quite lacking.

 

Basically I have a /downloads folder in /appdata on the cache pool

sab downloads to this, then sonarr and radarr move them to TV or Movies (respectively). However since the TV and Movies user shares are set to use cache, rather than just moving the file within the cache drive, it is creating a new duplicate file in the TV or Movies share, then deleting the original from the downloads share.

Esentially this is causing extra write to the cache drive (once when it downloads, the once again when it unpacks - this is normal obviously, but then it write the same data again within the cache pool in the correct user share instead of simply moving the file)

I am not sure if this is a linux/mover/copy limitation, or if I have something setup incorrectly.

 

I am not concerned about time, as these are NVMe drives, however that is WHY I am concerned, I don't want to burn out the drives early.

13 minutes ago, benyaki said:

simply moving the file

What you're seeing is normal, and expected, and happens on all OS's (including Windows)

 

You've presumably set up sonarr / radarr path mappings something akin to:

 

/downloads -> /mnt/user/downloads

/media -> /mnt/user/media

 

Sonarr / Radarr have to relocate the file from /downloads to be /media.  At first thought you'd think that the system could simply rename the file.  Except that the file exists at /downloads/myMedia.mkv, and you want it to be renamed to /media/myMedia.mkv

 

The only way to do that is to copy / delete the original, because there is no other way possible to move a file from /downloads to /media.  IE:  You can't move a file via renaming between two mount points.

 

Your alternative to this is to simply reference everything on all the containers as /mnt -> /mnt, and then renames will happen.  But, then because the system allows renames, the destination file may wind up on a disk in apparent violation of the include / exclude rules and the use cache settings.

Just now, Squid said:

What you're seeing is normal, and expected.

 

You've presumably set up sonarr / radarr path mappings something akin to:

 

/downloads -> /mnt/user/downloads

/media -> /mnt/user/media

 

Sonarr / Radarr have to relocate the file from /downloads to be /media.  At first thought you'd think that the system could simply rename the file.  Except that the file exists at /downloads/myMedia.mkv, and you want it to be renamed to /media/myMedia.mkv

 

The only way to do that is to copy / delete the original, because there is no other way possible to move a file from /downloads to /media.  IE:  You can't move a file via renaming between two mount points.

 

Your alternative to this is to simply reference everything on all the containers as /mnt -> /mnt, and then renames will happen.  But, then because the system allows renames, the destination file may wind up on a disk in apparent violation of the include / exclude rules and the use cache settings.

Thanks for the quick reply.

I figured thats what the issue was, just wanted to be sure that I didn't mess up some paths that was causing a problem.

Now, that being said, is there a better way to handle downloads with a cache to reduce writes? I would rather not have the media not use the cache drive, and since I have a gigabit connection with simultaneous unpacking/moving, I would rather not use spinners. I assume the way that I have it is the standard?

6 minutes ago, Squid said:

reference everything on all the containers as /mnt -> /mnt,

 

6 hours ago, Squid said:

 

Thanks. (This is why you don’t read a response on one device and answer on another.)