So over the weekend I seemed to run into an issue where my Cache drive was full (110gb free still). 2x 500gb SSD's in cache pool.

 

I have a few questions running RC9.

1) Docker, can I reduce the size of my docker container?

2) NZBget sometimes has a big queue, or its finished with a bunch but mover hasnt kicked in yet. (question for this below)

 

Can I get a 1tb drive and make it the download, unpack, storage location for nzbget?

Keep all config and everything on the main pool'd cache, but get an extra 1tb drive just to hold the downloads as they come in, or get unpacked, and then get things like Sonarr to pick it up?

That way it can leave my main cache alone, wont affect unRAID or any VM's that are running.

 

I'm sure I have more questions regarding this but brain is dead.

I use a Samsung 256gb 950 pro ssd for my downloaders to save into.
So the actual docker is on my cache, but it all gets saved (temporarily) to a unassigned disk (so that it doesn't affect parity). I have it unpack as it downloads individual parts, so the CPU hit isn't as great. Works wonders for me

Sent from my SM-G935F using Tapatalk

I have a 2TB WD Blue dedicated for downloads (using unassigned devices), setup works well.

Post processing activities then copy it to the array.

Edited October 16, 20178 yr by tjb_altf4

Is there any guide on getting this setup?

 

Also, if I do this and lets say use an unassigned drive, NZBget downloads to this drive, and unpacks.

Sonarr picks up the show and renames it and files it correctly in Media (how does this work with an unassigned drive and mover?)

 

I don't use my cache for downloading as (i) it's a waste of SSD lifespan as it's only going to get written to the array when the mover has to kick in (probably before you've watched the download) (ii) I don't need SSD write speed for 'background' activity

 

What I do is assign my downloads share to one array disk to minimise disk spin-ups, then have an import share on the same disk for completed downloads and my various media apps then move the completed downloads to their respective shares on the array.  I've chosen the disk that is pretty much on all day as it has the most accessed files i.e. it's already spun up

 

If I was going for silence during the days I'd use the cache drive or an unassigned SSD like @marshy919 but the file would still need moving to the array at some point i.e. you can't avoid the spin-up, although this could be overnight if you have a big enough SSD or not too many files downloaded.

Edited October 16, 20178 yr by DZMM

If you've got an MLC SSD, then you really don't need to concern yourself about endurance.  It's only TLC drives that burn out quickly. 

 

For example, I had a TLC Samsung 750 EVO that burned though 10% life in a month.  Replaced it with a MLC-based Samsung SM961 and over a year later it's still not used 1% life.

Edited October 16, 20178 yr by HellDiverUK

Thanks guys

 

Got a 1tb drive coming tomorrow which I'll just use for download directory.

Edited October 16, 20178 yr by SavellM

I would just add that 1 TB drive into the array (so not using unassigned devices), and then create a user share that you limited to that new disk. And put your downloads in there..

 

That way you have that drive parity protected also, maybe the data is not that important but combined with the user share it means that a fail of that disk will only need a new disk, no configuration, and if you want to in the future it is also quite easy to move that user share to another drive, or start using an extra drive for that share.. 

3 hours ago, Helmonder said:

I would just add that 1 TB drive into the array (so not using unassigned devices), and then create a user share that you limited to that new disk. And put your downloads in there..

 

That way you have that drive parity protected also, maybe the data is not that important but combined with the user share it means that a fail of that disk will only need a new disk, no configuration, and if you want to in the future it is also quite easy to move that user share to another drive, or start using an extra drive for that share.. 

 

This is kinda what im going to do.

I've added it to the array, and now going to add the download share to only this drive.

 

I've set nzbget to only postprocess at certain times, so once its unpacked it doesnt auto wake up the other drives and keeps it all for a certain time.

 

Kinda a long winded work around especially if I want the show right there and then. But it also saves the drives a bit

1 hour ago, SavellM said:

 

This is kinda what im going to do.

I've added it to the array, and now going to add the download share to only this drive.

 

I've set nzbget to only postprocess at certain times, so once its unpacked it doesnt auto wake up the other drives and keeps it all for a certain time.

 

Kinda a long winded work around especially if I want the show right there and then. But it also saves the drives a bit

 

I understand the sentiment... But in reality it is not at all a certainty that you are saving your drives... They are really build to be run.. 

9 minutes ago, Helmonder said:

 

I understand the sentiment... But in reality it is not at all a certainty that you are saving your drives... They are really build to be run.. 

Umm you're right.

I'm kinda torn between just letting my drives run 24/7 (my old Synology was like this and I never had a drive fail in like 4 years).

OR being super efficient and saying sleep after 2 hours of non-use and then doing work arounds like the above.

 

Not sure which is best

There's no rule that says your cache drive needs to be an SSD.  My cache drive primarily hosts Dockers that perform unattended operations.  I've got an HD in there right now - works fine and I don't care how fast it is since I don't sit and watch it.  I'm starting to think a 7200rpm laptop HD is nice combination of low power and fewer concerns about TBW for servers where the cache drive is primarily hosting high I/O media applications.  Need to calculate longevity, though.

From my perspective:

 

While unraid is a solution that can run on a wide variety of (inexpensive) hardware, when your needs grow your server needs to follow.  I can easily say that my unraid server has become an expensive beast when I talk about the initial hardware, the base power footprint, etc.

 

From my point of view the really only couple of euro's I could save by having a disk last a little bit longer or the power bill beiing fractionally lower; those things really do not have any significant impact on the overall cost.. So I just go for maximum user friendlyness and comfort and leave everything running..

 

Ofcourse there an environmental standpoint you could take that could also be a reason to save.. I have not taken that into consideration here. 

HAHA ye I know that feeling.

I replaced my little i5 Xpenology setup to give me something with a bit more functionality and customisation. 

 

But unRAID has started to cost me a lot more

Decided to do it properly, so Xeon with ECC ram and all in.

 

But its been a great project so not complaining at all.

Hopefully I've built something way better than before and should last a lot longer.

On 10/20/2017 at 7:05 PM, tdallen said:

There's no rule that says your cache drive needs to be an SSD.  My cache drive primarily hosts Dockers that perform unattended operations.  I've got an HD in there right now - works fine and I don't care how fast it is since I don't sit and watch it.  I'm starting to think a 7200rpm laptop HD is nice combination of low power and fewer concerns about TBW for servers where the cache drive is primarily hosting high I/O media applications.  Need to calculate longevity, though.

 

For most people this is a good solution, but anyone running Plex with a big library will really notice things slow down dramatically using a HDD, assuming the Plex Library (metadata, database, etc) is stored on the cache.  All those millions of tiny files really slaughter performance on a Plex box using a HDD.

2 hours ago, HellDiverUK said:

 

For most people this is a good solution, but anyone running Plex with a big library will really notice things slow down dramatically using a HDD, assuming the Plex Library (metadata, database, etc) is stored on the cache.  All those millions of tiny files really slaughter performance on a Plex box using a HDD.

 

Is there any way to double check or know my library is set to use my SSD Cache?

10 minutes ago, SavellM said:

 

Is there any way to double check or know my library is set to use my SSD Cache?

If you're using a Plex docker, then it'll store in wherever your appdata share is.

15 minutes ago, HellDiverUK said:

If you're using a Plex docker, then it'll store in wherever your appdata share is.

Cool thought so... Just double checked and im good