If an opportunity arises to respond to this elsewhere, I will. I don't think I'll dump on btrfs in a btrfs thread, though :)
Keep in mind though I wrote all that ~10 years ago, and it was very much an opinionated mission statement. bcachefs started out 15 years ago as a couple of us sitting around in the office drinking beers "you know, this looks like a really elegant basis for a filesystem, it's going to be way smaller and cleaner!" (talking utter shit, of course). But, somehow, I stuck with it...
That's nice. The point being a 10 year old, self-confessed 'opinionate mission statement' which has in the intervening years seen some notable pushback (and perhaps progress in the opposition) should not be trotted out as the grandparent did and presented as a case of cadit quaestio.
I don't see anything there that's fundamentally changed. Btrfs repair code is still quite weak, and "btrfs ate my data" stories have reduced somewhat, but I'm still seeing them come up, and the core architectural issues haven't changed. Josef was recently saying on lkml that they (the btrfs team, at least at facebook) have accepted that XFS will always be better in many scenarios, and to me that's an admission of failure - a COW filesystem should work just as well as a previous generation non-COW filesystem in nocow mode.
A mission statement like that is fundamentally saying "these are my priorities, this is why we need to do better" and I stand by what I wrote, because taking on writing a new filesystem - the part of the operating system with the highest requirements for "this absolutely has to work" robustness - really is about having the right priorities.
Gotta take your time your time to get things right, make sure the fundamentals are solid, before chasing all the features - this isn't an area where typical silicon valley "go big or go home, fake it till you make it" attitudes can work.
I don't see anything there that's fundamentally changed.
Yes, I rather think that's the point. And this is clearly the point at the party where I find an excuse to move on from the very earnest person who's decided that something is wrong on the internet and say "sure man...good luck with that".
Yes, the low level format for btree nodes/btree keys isn't changing, and the fact that it's a database does ease a lot of backwards and forwards compatibility issues - for example, most key types can have new fields appended and old versions will just ignore the new field.
But schema changes can still be pretty impactful.
The big on disk format changes were:
- accounting rewrite in 6.11, which switched from a high performance, but complex and difficult to extend mechanism where accounting was stored in memory with percpu counters and then bundled up in each journal entry, to storing them in btree keys and journalling them as deltas.
The runtime code was so vastly different that it just wasn't possible to keep writing out the old accounting without retaining all of the old code side by side with the new code - it would have been really gross.
- backpointers change in 6.14, for fsck scalability improvements
This one would have been possible to do without rewriting all the backpointers, but that still would've had severe downsides. The main option would've meant permanently inflating the size of the backpointers btree by ~20%, IIRC, and backpointers are almost half of all metadata on a typical filesystem. There were ways to get around that, but they would've added a lot of complexity that we would've had to carry around forever.
But those are exactly the sorts of things the experimental phase is for - getting it on more and bigger systems and seeing what shakes out and finding out what we still need.
Honestly the ability to do those major changes in place are pretty exciting and might be a draw towards BcacheFs for me. As long as it doesn't happen too often (with the experimental phase as an exception) it's really nice to be able to benefit from major features and improvements.
I really dislike the attitude some FS devs have that if you want some improvement made after you setup a system you should just reformat and restore from backup.
Sure a 5 hour metadata rewrite is disruptive, but it's nothing compared to a 5 day backup, reprovision, restore dance. The former can run over night on a weekend, the latter takes basically the entire work week. Therefore it won't get done until all the infrastructure is EOL, and replaced with something else 3-7 years down the line.
Every filesystem has had data corruption bugs. Unfortunately, that's just how it is with the complexity of modern filesystems and the tools we have.
(We're still coding in bloody _C_).
What you really don't want is to be losing entire filesytems. A single file here and there getting corrupted is one thing, and it's usually highly workload dependent so it'll probably only hit one application, but losing an entire filesystem is much more impactful.
ext 2/3/4 has the best track record here (and note, it's also had data corruption bugs), with the relatively simple on disk format and e2fsck being quite robust. XFS is probably next up, I've seen reports of XFS filesystems being lost but only one or two - a tiny, tiny fraction of the btrfs reports. Can't speak as much to ZFS.
Perhaps down the road, after experimental is lifted. For now I've generally been telling distros to slow down.
For anything this big staging the release is important, we don't need or want to be in every distro right away (the Fedora people were also _extremely_ gung ho in the past and I told them the same thing).
Until every outstanding critical bug report is fixed (and there are still a few), I want power users testing it who know how to deal with things breaking, I don't want unsuspecting users getting bit.
Devil's advocate: You may find that it better achieves your goal to provide packages and say "For power users testing only". You might also be able to petition Debian to have it removed if it's leading to people foot-gunning.
If I can help with deb/rpm packaging, let me know. I'm a power user here, excited about bcachefs, but haven't tried it because I don't have the time to give it a worthy test (remembering how much time I put into getting ZFS stable on Linux). Thanks for your hard work on it!
A large part of the issue here was the snafu resulted in Debian users not getting updates for months for a critical fix, and then not being able to mount in degraded mode, and I was the one fielding those bug reports.
Okay, so ask if they're using your packages or the distro packages, and if it's the latter tell them to talk to the person who maintains those packages. If it was me I would have that be part of the bug report form up front, but I don't know what your process is.
That's just passing the buck, it doesn't do anything for the users who were affected by the very real screw up
It also doesn't work in practice because I have to do most of the diagnosis before I find it if it's my bug or Debian's.
The only real solution is for Debian to be better at working with upstream, and not do things they've been told are going to cause problems, and not drop the ball when they do.
> It also doesn't work in practice because I have to do most of the diagnosis before I find it if it's my bug or Debian's.
No, you ask that first and if it's a downstream package you stop working on it. If the downstream maintainer determines that it is on your end and not theirs, then you can pick it back up.
> The only real solution is for Debian to be better at working with upstream, and not do things they've been told are going to cause problems, and not drop the ball when they do.
Assuming that "working with upstream" means "adopting upstream code in direct contravention of their own policies": If your solution depends on Debian not being Debian, then it's unlikely to work.
> No, you ask that first and if it's a downstream package you stop working on it. If the downstream maintainer determines that it is on your end and not theirs, then you can pick it back up.
They're not going to devote that kind of time. That just means bugs not getting looked at or fixed.
> Assuming that "working with upstream" means "adopting upstream code in direct contravention of their own policies": If your solution depends on Debian not being Debian, then it's unlikely to work.
I'm not sure why you think that policies that are causing problems shouldn't change.
Again: they volunteered to package it, they did it badly and users were affected. Until they can get their act together, bcachefs-tools won't be in Debian.
That's ok. There are other distros, and there's no rush.
Linus can be a bit of a dick sometimes (and hey, so can I), but he's not prone to being rash or a petty tyrant. He just rides people a bit hard.
Following process to the letter isn't what we should be doing right now; this isn't the time for slowing down to cross every t and dot every i, this is the time for getting fixes pushed out quickly so we can move on to the next thing.
But things have also been stabilizing dramatically, it's already looking like I'll have a lot less out of merge window stuff to send this cycle (there wasn't much that I would've sent last cycle, either).
Oh, the author's completely misrepresenting what happened here.
We had a major snafu with Debian, where a maintainer volunteered to package bcachefs-tools (this was not something I ever asked for!), and I explained that Debian policy on Rust dependencies would cause problems, and asked him not to do that.
But he did debundle, and then down the road he broke the build (by debundled bindgen and ignoring the minimum version we'd specified), and then _sat on it for months_, without even reporting the issue.
So Debian users weren't getting updates, and that meant they didn't get a critical bugfix that fixed passing of mount options.
Then a bunch of Debian users weren't able to mount in degraded mode when a drive died. And guess who was fielding bug reports?
After that is when I insisted that if bcachefs-tools is packaged for debian, dependencies don't get debundled.
If you're going to create a mess and drop it in my lap, and it results in users not able to access their filesystem, don't go around bitching about being asked to not repeat that.
That last one’s great advice. I don’t remember if you can use checkboxes there and I’m too lazy to look at the moment, but I could imagine the first question being:
I seem to recall a previous fs creator with ego problems was tried and convicted of murder, and then his work unceremoniously disappeared into an oubliette.
I’m 99% sure you’re joking but as an outsider I have… concerns.
Genuinly curious: it seems like you are making a remark on his character, right? But why did you do so? Just fed up? Or did he actually state something wrong in the parent comment?
But doesn't your global liberal democratic society want you to be trained and proficient in productive tasks which might only appear boring through a superficial lens or perspective? Or is this world's education entirely motivated by the selfish desire for pleasure and leisure? Rather than being founded to serve hard work ethic principles and effective programs that maybe can help build decent societies?
reply