Best redundancy option for 4 bay ITX case?

draetheus

Dabbler
Joined
Oct 3, 2013
Messages
13
I'm planning out a new TrueNAS ITX build with 4 bays. Historically I have always ran all 4 bays with RAID-Z1 (or RAID-5 on other systems), however I am more paranoid than I used to be. With HDD capacities as high as they are now, I would be fine using the extra bay for redundancy rather than capacity. Having only 4 bays leaves me with a lot of options:
  • Mirror + Stripe
  • RAID-Z2
  • RAID-Z1 with hot spare (I assume this isn't a good option based on what I've read)
  • RAID-Z1 with completely separate disk for backup (for example, 3x8TB drives in Z1 + 16TB backup drive)
This NAS is for home use, with a focus on video capture, editing, and conversion.
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Just from a pool resilience viewpoint, here's what can happen as you lose a disk and then a second one (disk labeled A-E).

Yellow is a degraded VDEV/Pool and Red is an entirely dead pool.

1617020981768.png


Clearly if pool resilience is your priority, RAIDZ2 is the option.

With a hot-spare, you may still lose a second disk during resilver (which stresses the remaining disks heavily), so it's potentially no better than without the hot-spare in that case.
 

nick779

Contributor
Joined
Dec 17, 2014
Messages
189
Just from a pool resilience viewpoint, here's what can happen as you lose a disk and then a second one (disk labeled A-E).

Yellow is a degraded VDEV/Pool and Red is an entirely dead pool.

View attachment 46212

Clearly if pool resilience is your priority, RAIDZ2 is the option.

With a hot-spare, you may still lose a second disk during resilver (which stresses the remaining disks heavily), so it's potentially no better than without the hot-spare in that case.

So, I'm not here to disagree but merely as someone in the same position. Z2 vs mirrored vdevs for 4 disks.

While Z2 is definitely more fault tolerant, does this account for A the performance degradation and B the resliver stress?

Rebuilding a Z2 is going to stress ALL of the disks and poses a very real chance to get a URE from another drive if not cause it to fail altogether.

Again, just keeping a conversation going as I've been racking my brain over this same scenario. Easy resliver/copy from one disk vs random reads and parity calcs across all drives. I favor Z2 as well, but "R10" really has me thinking about the reduced resliver stress.
 
Last edited:

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
RAIDZ2... Lose one drive, start resilver, lose a second due to resilver, still OK (but no more redundancy until the resilver is done), do another resilver, lose another drive, still OK (again no redundancy until resilver is done).......

Mirrors... Lose one drive, start resilver, lose a second drive due to resilver (less likely but still an option), pool dead.

If you can run a scrub (which all disks in a healthy pool must be capable of), then resilvering will be OK too.

I'm just pointing out the redundancy story, no criticism of anyone's ideas.

I think there's something to be said about paying close attention to SMART tasks and their output as drives age to (or beyond) their MTBF where the scenario may be more dangerous with RAIDZ2 as stated due to the load of a resilver tipping more than one drive over the edge at the same time.

Folks with a real love of their data may want to consider pro-active drive replacement, replacing aging drives with no SMART errors to avoid that additional risk.
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Easy resliver/copy from one disk vs random reads and parity calcs across all drives
One of my first posts to this forum was the observation that a mirror performing a resilver in a pool of multiple mirrors (you're calling "R10") was causing the pool to show activity on all VDEVs, which was determined to be a result of the resilver process effectively re-using the scrub code for parts of its work.

I have no idea if this has been fixed in OpenZFS 2.0 (it was a long time ago), but I'm not sure that it's not still the case.
 
Top