7
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 04 Aug 2023
7 points (81.8% liked)
Selfhosted
39677 readers
164 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
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.