Server architecture: is a scratch drive worth it?

[antioch18]

I'm putting together a new Home NAS which will, among other things, be on download duty. I've seen builds around that use a scratch drive to store the temporary files being downloaded, runs processing on the files (parity check) while on the scratch disk, then extracts from scratch to primary storage array.

This sounds interesting in theory as I understand it attempts to save some wear on the main array, and also gets you better throughput on the extraction step (extraction where source and destination drives are different is faster than when they're the same). However, my main array is RAIDZ2 (running with ECC RAM, of course) and as such I think that this means to do it "right" the scratch drive would also need to be a ZFS array? If so, it seems kind of overkill to throw in an additional *two* disks for the benefits proposed by having a scratch drive. Although I guess I could have a single ZFS format drive with copies=2 in order to get error correction?

I wonder what you thoughts are on this idea?

 

[EffrafaxOfWug]

It depends a great deal on what your download method(s) are and how many you expect to be doing at once I suppose, but I don't see a huge advantage in it. Most torrent clients for example will pre-allocate the whole file and fill in blocks as and when they're pulled down, much reducing fragmentation and random IO. ZFS already takes a lot of steps to reduce random IO as well.

If you've got space for extra storage (or maybe just some leftover space on your boot SSDs) then it doesn't hurt to set up a small volume there for downloading stuff (so that your main array never sees any random IO during downloading) but if you don't it's almost certainly not worth the extra effort and expense.

 

[JSchuricht]

Parity checking makes me think of PAR files. If that's the case, a good SSD does make a huge difference vs trying to do it on a mechanical array. It will also help with assembling chunks and unraring.