That one is something I really disagree with. I don't mean to say that everyone should use RAIDZ, but that article is way too dismissive of RAIDZ (going from memory, it's not loading at the moment). In particular, for storing media - let's be realistic, in this context, any meaningful volume of data to be stored will be large files of some sort - the performance concerns are misplaced and wasted space due to small blocks is a non-issue.Unless you really, really know what you're doing, lean towards a pool of mirrors rather than RAIDz.
Well, if the whole volume is a goner, a single bit out of place seems like a minor concern, that's the main gripe with btrfs.My reading of the OPs question was a concern over bit rot, and if either ZFS or BTRFS had an advantage in that area.
Two points:Secondly, what are the must have use cases for a home lab enthusiast to have RAID (of what ever flavor)? Leaving aside the Youtube content creators and people running a business, what use case absolutely demands this level of resilience? (...)
I assume we can all agree that RAID is not a replacement for a good backup strategy?
To detect bitrot. you need checksums on data and metadata. To be protected against a corrupt filesystem due a crash during write you need "Copy on Write". Btrfs and ZFS have them both while ZFS has some performance relevant extras like special vdev tiering, persistent ssd readcache and protection of the rambased writecache via slog.My reading of the OPs question was a concern over bit rot, and if either ZFS or BTRFS had an advantage in that area. I have seen no data that shows any difference in bit rot protection, scrubs, or snapshots between the two file systems. Is there any difference (leaving aside the RAID aspects/questions) say in a single disk or JBOD array not set up as a RAID?
The enemy of data is statistics. With a low propability you have bitrot (data on disk is bad) or other readerrors that cannot be repaired by disks itself. The number of such errors is proportional to pool size, usage time and pool load. With a multi terabyte pool that you use or backup regularly you have errors within its usage time for sure. Checksums detect such errors on read or pool scrub but then? With btrfs or ZFS raid redundancy the error is repaired automatically. Without btrfs or ZFS raid redundancy you get informed about a bad file and must restore manually from backup.Secondly, what are the must have use cases for a home lab enthusiast to have RAID (of what ever flavor)? Leaving aside the Youtube content creators and people running a business, what use case absolutely demands this level of resilience? I mean, who has a contractual service level penalty associated with their Plex server?![]()
It is not that easy.I assume we can all agree that RAID is not a replacement for a good backup strategy? I can't think of many (any?) use cases that really require it at home other than if you are just trying to learn the technology. I would love to hear what other folks think.
Some people like to collect data, in my case I like to keep my photos which goes back +20 years. And my music (ripped CDs). That is a very good reason for having raid(6) and offsite backup.Secondly, what are the must have use cases for a home lab enthusiast to have RAID (of what ever flavor)? Leaving aside the Youtube content creators and people running a business, what use case absolutely demands this level of resilience? I mean, who has a contractual service level penalty associated with their Plex server?I assume we can all agree that RAID is not a replacement for a good backup strategy? I can't think of many (any?) use cases that really require it at home other than if you are just trying to learn the technology. I would love to hear what other folks think.
I've been running a raid6 setup for +10 years and until now the only problem I've had is 2 dead drives (3 years apart). I have exclusively used it with ext4.You know that raid-6 protects against up to two bad disks but does not protect against a corrupt filesystem or raid structure when the system crashes during a write, "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.
Copy on Write filesystems combined with btrfs or ZFS software raid are not affected by the write hole problem.
And: How sure can you be that data or backup is good without checksums?
Except that it is, here's the quote straight from the horse's mouth:Copy on Write btrfs (...) not affected by the write hole problem.
The RAID56 status intro is also a good one:The write hole problem. An unclean shutdown could leave a partially written stripe in a state where the some stripe ranges and the parity are from the old writes and some are new. The information which is which is not tracked. Write journal is not implemented. Alternatively a full read-modify-write would make sure that a full stripe is always written, avoiding the write hole completely, but performance in that case turned out to be too bad for use.
Translated into practical reality, "RAID56 works fine except when it doesn't, and it's so terrible we really should just remove it outright."The RAID56 feature provides striping and parity over several devices, same as the traditional RAID5/6. There are some implementation and design deficiencies that make it unreliable for some corner cases and the feature should not be used in production, only for evaluation or testing. The power failure safety for metadata with RAID56 is not 100%.
I think this is mostly true, but I believe and correct me if I am wrong, if you are doing regular snapshots, either file system can correct the error from a previous snapshot if the snapshot contains good data. Plus both file systems store redundant copies of the metadata so if the error is in the metadata, that can be corrected automatically. Am I understanding this correctly?With btrfs or ZFS raid redundancy the error is repaired automatically. Without btrfs or ZFS raid redundancy you get informed about a bad file and must restore manually from backup.
You are wrong.I think this is mostly true, but I believe and correct me if I am wrong, if you are doing regular snapshots, either file system can correct the error from a previous snapshot if the snapshot contains good data. Plus both file systems store redundant copies of the metadata so if the error is in the metadata, that can be corrected automatically. Am I understanding this correctly?
So are you saying Illumos for the win here? ;-)This is not related to ZFS. On BSD and LInux you always use SAMBA that knows nothing about ZFS. Only difference are SAMBA settings and defaults by a distribution. ZFS related are only ZFS properties like aclmode or aclinherit that work on filesystem level not share level.
Only when you use a Solaris based ZFS system with the OS/kernel/ZFS based SMB server instead SAMBA, situation is different as this comes with Windows ntfs alike nfs4 ACL instead simpler Posix ACL, use shares as a strict ZFS property that allows ZFS snaps as Windows previous versions without special settings or considerations, can use local SMB groups that can contain groups and use Windows SID ex S-1-5-21-722635049- 2797886035-3977363046- 2147484648 as security reference instead simpler Unix uid like 101 with the then needed complex mappings on a backup system or after a filesystem replication.
They have a vested commercial interest in said software, so of course they'll tout it. They just never disclose that in their posts.So are you saying Illumos for the win here? ;-)