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 post was submitted on 29 Nov 2023
54 points (96.6% liked)
Linux
47952 readers
1181 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
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!