- cross-posted to:
- btrfs
- cross-posted to:
- btrfs
You must log in or # to comment.
I can’t say I’m a huge fan of btrfs, in my limited sample size of one I had several episodes of esoteric errors and data loss. It’s anecdotal but filesystems have never been something to give me trouble in any other scenario to date. They just exist and do their job silently in my experience, except for btrfs.
This is what I thought too, but in my case it turned out my drive was busted and btrfs detected an error and went read only… which was super annoying and my initial reaction was “ugh, piece of shit filesystem!” But ultimately I’m grateful it noticed something was wrong with the drive. If I was just using ext4 I just would have had silent data corruption. In that sense other filesystems do silently do their jobs… but they also potentially fail silently which is a little scary. Checksums are nice.
This is the best summary I could come up with:
The new API avoids overloading a single system call and allows for providing more control over the mount.
The mount API is described by Christian Brauner in this 2020 OSS EU presentation:
Brauner a few months ago sent out a set of patches for working on adapting Btrfs to make use of this new mount API while Josef Bacik also worked on this support too and that implementation is now what’s on track for mainlining in Linux 6.8.
Queued into the Btrfs kernel development tree’s for-next branch as of last week is the code for switching Btrfs over to using the new mount API and in turn stripping out the old mount code.
More context for those interested can be found in the prior mailing list series.
The Linux 6.8 merge window should be opening up around the end of the calendar year.
The original article contains 207 words, the summary contains 143 words. Saved 31%. I’m a bot and I’m open source!
