Link: Examining btrfs, Linux’s perpetually half-finished filesystem

September 24, 2021

Ars Technica's Examining btrfs, Linux’s perpetually half-finished filesystem (via) is not very positive, as you might expect from the title. I found it a useful current summary of the practical state of btrfs, which is by all accounts still not really ready for use even in its redundancy modes that are considered "ready for production". There's probably nothing new for people who are actively keeping track of btrfs, but now I have something to point to if people ask why we're not and won't be.


Comments on this page:

By mappu at 2021-09-24 20:15:10:

I really wish this author would disclose that he is a mod of r/ZFS.

His articles are highly biased - including in the past, famously blaming SMR drives for poor RAIDZ performance despite mdadm handling them fine (being block-based raid instead of file-based - file-based RAID with its extra seeking is nonsense on spinning rust drives anyway).

This article amounts to "btrfs is a great filesystem but upstream don't recommend the RAID5/6 code" and then describes all the RAID features anyway. He then complains about the multi-device syntax for mount/umount, while conveniently forgetting that ZFS can't mount via mount/umount at all and requires an entirely separate program for that.

Very disappointing take

By Blissex at 2021-09-26 16:33:40:

Bot the "Salter" article and the "mappu" comment seem to me fairly incorrect, because Btrfs works pretty well in some large applications and has significant problems in some others.

Btrfs works well (good to excellent speed, high reliability) without using the multiple-device mode, and without doing many subvolumes/snapshots. As a normal filesystem with checksumming and subvolumes/snapshots (but not too many) is pretty good. That is the core design by Rodeh and Mason is very good. Note: Btrfs like "bcachefs" and "f2fs" seems to work very well on SMR devices for many workloads.

The problems with the various "RAID"-alike modes are not those described by "Salter" etc, they are related to some severe misdesign decisions as to what it means to remove/replace devices, in all modes except "RAID10"-alike. Without those the "RAID1"-alike mode would be fairly good. I think that the multiple-device storage layer was simply misdesigned by people unfamiliar with storage administration.

A very good feature of Btrfs is that however it allows different layout modes for metadata and data, and in particular allows having duplicated metadata on single drives, which is very important when using checksums (OpenZFS mandates metadata duplication).

Side notes: the RAID5/RAID6 debate on Btrfs is fairly ridiculous as to the core issue ("write hole"): MD RAID itself had the same core issue until "recently" and I think that still most MD RAID users don't use the journal feature to avoid the "write hole". However I also think that the RAID5/RAID6 code of Btrfs is (or was) not written carefully, regardless of the "write hole" core issue. I personally would not use the RAID6 mode, while I think that the RAID5 mode as usable (for data) as the without-journal RAID5 mode of MD RAID.

Regardless of all this, there are several people who have large storage device arrays with Btrfs, even with RAID1 and RAID5, quite successfully (the corner cases are rare in practice).

I have mixed feelings about both Btrfs and OpenZFS because the code is enormous and convoluted, and while they have been extensively debugged, that suggests caution. There is also the upcoming "bcachefs" which is somewhat more similar to Btrfs and I think has a much better code base.

Some links:

http://www.sabi.co.uk/Notes/linuxBtrfs.html https://btrfs.wiki.kernel.org/index.php/Gotchas (some things may have improved)

By Todd at 2021-10-02 15:28:08:

Heh. I read that article thinking, "Oh boy. Chris is gonna love this article if he finds it." It appears I was right. = )

Written on 24 September 2021.
« Go generics have a new "type sets" way of doing type constraints
Understanding EGL, GLX and friends in the Linux and X graphics stack »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 24 12:07:48 2021
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.