I’m looking at different options for getting a NAS/RAID array system that is tolerant to not just hard drive failures but also to hardware/firmware and board failures. I’ve utilized a RAID array in the past that was built into the motherboard, which resulted in the motherboard failing and me having to ebay another one to get the RAID array back up and running. Then I bought a NAS 2 bay drive that was only compatible with drives up to 1.5TB. I’ve also used external drives for backup since I’ve been burned by hardware/firmware/software issues related to RAID arrays. Are there are any PCI RAID cards, NAS boxes or software RAID or other options where the hard drives would still be readable by other RAID cards if the boards failed? Maybe a software RAID solution? Any thoughts would be appreciated.
Out of curiosity in your experience, are issues mentioned in this article actually fixed now? They mention the write hole, so that was fixed. What about the rest?
The crux of the matter is that the article’s criticisms of btrfs are largely based on its differences from ZFS, rather than any inherent flaws in btrfs itself. Notably, Suse Enterprise Linux, Fedora, and Meta’s Linux engineers all advocate for btrfs, using it extensively in production.
The article’s main grievances are:
Btrfs RAID Arrays:
The author is upset that btrfs RAID arrays don’t function as he anticipated. However, btrfs isn’t ZFS or mdadm; it’s its own system and should be understood as such. The author criticizes btrfs for allowing drives of mismatched sizes. This flexibility, however, isn’t inherently negative.
Btrfs RAID Array Management:
The author laments that btrfs can’t be mounted by a human-readable name like ZFS, and instead requires UUID. Using UUID is standard practice for native Linux file systems. A side note: mounting by drive letter is outdated; UUID is the recommended method.
Btrfs-RAID’s Redundancy:
The author points out that btrfs won’t auto-mount an array if a drive fails, while ZFS will. This is actually a protective measure. By not auto-mounting, it minimizes the risk of further drive failures, prioritizing data preservation.
Btrfs-RAID Maintenance:
The author’s complaint here boils down to “btrfs isn’t ZFS.” He attempts ZFS recovery methods on btrfs and is surprised when they don’t work. The processes are different, but that doesn’t mean btrfs is more labor-intensive.
He also critiques the use of crc32 for corruption detection. If this is a concern, other algorithms can be used. The default, crc32, is chosen for its speed. In fact, some argue that btrfs’s integrity checks are faster than alternatives.
In summary, the article’s author seems primarily upset that btrfs isn’t a ZFS clone. He overlooks btrfs’s advantages over ZFS, such as ZFS pools occasionally failing to mount due to kernel updates. On the other hand, major entities like Suse Enterprise Linux, Fedora, and Meta rely on btrfs in large-scale production environments.
When revisiting the article, keep the perspective of “an individual frustrated that btrfs isn’t ZFS” in mind. The bias becomes evident.