I don't really want to move /config onto the array. Given that it's so rare for me to dl files that large, perhaps I can just work around it like I did this time.
MOVE SABNZBD TO NEW COMPUTER ARCHIVE
It was a collection of many files: first the many rars, then many small files unpacked from them, which is why the Mover could do its thing while the archive was being unpacked (I was lucky in that regard). Like Scotty: "I canna give it any more, Cap'n!" or something like that. Yeah, I've never downloaded anything so large before - my fibre internet connection kept chucking a fit while it was downloading, too. If you had filled up the cache drive unRAID should have started writing to the array but I haven't put that to the test and I'd be worried about the final unpack where you were writing a single file to the cache drive that exceeds the entire capacity of the cache drive. I believe you'd have to change both the /config and /downloads directory in the docker volume mappings to move Sab's location onto the array. That's a big file.Ĭheck your volume mappings for the docker as well as Folders in Sab. Sab is behaving how it's "generally" supposed to, but "generally" doesn't anticipate 200GB files.
What would happen if I *didn't* invoke the mover while SABnzbd was extracting a huge archive? Like, say I'm away from my computer while this happens - will it end in catalcysm? Or will it just start writing directly to the array like it ain't no thang? I didn't want to risk the scenario, which is why I invoked the mover so many times, but if the archive extraction seamlessly starts extracting to the Array, then it won't be a problem, will it?
So it must be a setting somewhere else, yes? How do I stop SABnzbd from using the cache drive for its temp folder? I have set the incomplete_downloads folder to /mnt/user/bigfiles/sabnzbd/incomplete (as at the moment, that share does use cache, but I have previously set it to *not* use cache, and SABnzbd still stored the downloading files on the cache drive (I could see it filling up). So, after all this, I have two questions: I was unsure if the mover would be happy performing this, but it seems to be working fine. It won't use the cache drive, and I will set it as the destination for a particular SABnzbd category - if I'm wrong in this solution, please let me know).Īnyway, I only noticed that it was unpacking to the cache when I got a warning that the cache drive was filling up, so I invoked the mover, and it seems to be emptying only a fraction slower than it's filling up as the files unpack, so I think I've avoided it becoming critically full. As such, I think I've solved the unpacking part of the problem (I'll create a 'large SABnzbd files' share that big SABnzbd files can be extracted to.
MOVE SABNZBD TO NEW COMPUTER DOWNLOAD
Then, once the download had finished, I noticed that it was unpacking to the cache drive - I believe this is because it's extracting to a User Share that uses the cache, and I didn't think to disable that option until it had started unpacking. So a few times during the download I had to pause the download, stop SABnzbd, invoke the mover, then start SABnzbd + the download again after the mover had completed. I didn't think it was set to, but SABnzbd was saving the temp download files to the cache drive. For the first time yesterday I started downloading a NZB that was greater than the size of the cache pool (200GB). I have a 124 GB cache pool across two SSDs.