I am archiving a vast amount of media files that are rarely accessed. I’m writing large sequential files, at peaks of about 100MB/s.
I want to maximise storage space primarily; I have 20x 18TB HDDs.
I’ve been told that large (e.g. 20 disk) vdevs are bad because resilvers will take a very long time, which creates higher risk of pool failure. How bad of an idea is this?
I’ve been told that large (e.g. 20 disk) vdevs are bad because resilvers will take a very long time
They won’t really take any longer than on narrower vdevs unless you’re hitting CPU or controller throughput limits.
Draid mitigates a lot of the problems of very wide raidz
https://openzfs.github.io/openzfs-docs/Basic Concepts/dRAID Howto.html
Draid was released just a month after I built my last raid set with vdevs. Really hoping there’s an in-place migration path someday, assuming nobody finds any bugs in the next couple years.
I have a few 24x drive RAIDz3 pools, and as long as you can live with the longer scrub and resilver time they make a good archive or backup pool, but I would not really want it as an always on active pool. If you want to know what the estimated failure rate here is a calculator.
Not sure if its broken or if my mobile firefox browser just doesn’t like it, but I seem to be getting an error of 0% failure rates, there are other calculators if you google them though.
https://www.servethehome.com/raid-calculator/raid-reliability-calculator-simple-mttdl-model/
I’ve been told that large (e.g. 20 disk) vdevs are bad because resilvers will take a very long time, which creates higher risk of pool failure. How bad of an idea is this?
I normally only have to replace 1 drive at a time, but with RAIDz3 you have to lose 4 drives at the same time for data loss to happen. If you are using a mixed batches of drive (not all from the same run) this happening is very low, and usually happening due to some other event (overheating, fire, cow attacking the disk shelf) In the 5 years I have had these pools, the worst was losing 1 drive, and having errors pop up on another drive, which were still corrected because RAIDz3 has 3 drives of protection.
I always understood as a balancing act in your vdev sizing. Too big = long rebuild times with so many disks spinning up every time. too small = wasted $ with TB loss to redundancy (raidz2 with 3 20tb disks only utilizes 33% of the TB purchased).
I’ve always felt you should calculate how many disks do you need to saturate your connection and go from there. 10gig trunk on your network then you’ll want 1 vdev to be able to saturate a 10gig line. any larger than that you don’t get any benefit from.
That’s the ideal use case for snapraid.
Mergerfs + snapraid
If a drive fails, you only need the parity disk to restore, not the whole array. Also, if for some reason you can’t restore, you only lose data on the failed drive.
ZFS is great and for real NAS data, I’m a fan. But for large media files and and such that you are write once, read many, it’s a much better option I think.
Mergerfs is just to present all 20 drives as a single mount point so you aren’t searching thru 20 drives when you want to view.