You don't have to be to see bug reports, bug fix patches, or test it yourself, of course. "Filesystem guys" also tend to wear rose colored glasses when it comes to their filesystem, at times (ext2, xfs, btrfs, etc.)
Linus absolutely does jump in on VFS level bugs when necessary (and major respect for that; he doesn't rest on laurels and he's always got his priorities in the right place) - but there's only so much he can keep track of, and the complexity of a modern filesystem tends to dwarf other subsystems.
The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure.
And I wouldn't say that filesystem people in general wear rose colored glasses; I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson.
> Linus absolutely does jump in on VFS level bugs when necessary (and major respect for that; he doesn't rest on laurels and he's always got his priorities in the right place) - but there's only so much he can keep track of, and the complexity of a modern filesystem tends to dwarf other subsystems.
The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact.
> The people at the top explicitly don't and can't keep track of everything, there's a lot of stuff (e.g. testing) that they leave to other people - and I do fault them for that a bit; we badly need to get a bit more organized on test infrastructure.
Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale.
> And I wouldn't say that filesystem people in general wear rose colored glasses;
Perhaps that's what you see through your rose colored glasses? (sorry, just a cheeky dig).
> I would categorize Dave Chinner and Ted T'so more in the hard nosed realistic category, and myself as well. I'd say it's just the btrfs folks who've had that fault in the past, and I think Josef has had more than enough experience at this point to learn that lesson.
Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification.
I'm not singling out filesystem developers or any one person or even software development specifically. All complex projects need advocates and input from outside stakeholders (users, other software, etc) for this exact reason, is that those deep in the guts of it usually don't understand all perspectives.
> The point is he doesn't have to understand details of the code to see bug reports and code churn and bug fix commits and have a reasonable idea of whether it's stable enough for end users. I would trust him to make that call more than a "filesystem guy", in fact.
No, that's not enough, and I would not call that kind of slagging good communication to users.
Seeing bugfixes go by doesn't tell you that much, and it definitely doesn't tell you which filesystem to recommend to users because other filesystems simply may not be fixing critical bugs.
Based on (a great many) user reports that I've seen, I actually have every reason to believe that your data is much safer on bcachefs than btrfs. I'm not shouting about that while I still have hardening to do, and my goal isn't just to beat btrfs, it's to beat ext4 and xfs as well: but given what I see I have to view Linus's communications as irresponsible.
> Absolutely not on the top nodes. Testing has to be distributed and pushed down to end nodes where development happens or even below otherwise it does not scale.
No, our testing situation is crap, and we need leadership that says more than "not my problem".
> Dave Chinner for example would insist the file-of-zeroes problem of XFS is really not a problem. Not because he was flat wrong or consciously being biased for XFS I'm sure, but because according to the filesystem design and the system call interface and the big customers they talked to at SGI, it was operating completely as per specification.
Well, he had a point, and you don't want to be artificially injecting fsyncs because for applications that don't need them that gets really expensive. Fsync is really expensive, and it impacts the whole system.
Now, it turned out there is a clever and more practical solution to this (which I stole from ext4), but you simply cannot expect any one person to know the perfect solution to every problem.
By way of example, I was in an argument with Linus a month or so ago where he was talking about filesystems that "don't need fsck" (which is blatently impossible), and making "2GB should be enough for anyone" arguments. No one is right all the time, no one has all the answers - but if you go into a conversation assuming the domain experts aren't actually the experts, that's not a recipe for a productive conversation.
> No, that's not enough, and I would not call that kind of slagging good communication to users.
It is enough. Users need to be told when something is not stable or good enough.
> Seeing bugfixes go by doesn't tell you that much, and it definitely doesn't tell you which filesystem to recommend to users because other filesystems simply may not be fixing critical bugs.
Cherry picking what I wrote. Bugfixes, code churn, and bug reports from users. It certainly tells someone like Linus a great deal without ever reading a single line of code.
> Based on (a great many) user reports that I've seen, I actually have every reason to believe that your data is much safer on bcachefs than btrfs. I'm not shouting about that while I still have hardening to do, and my goal isn't just to beat btrfs, it's to beat ext4 and xfs as well: but given what I see I have to view Linus's communications as irresponsible.
Being risk adverse with my data, I think Linus's comment is a helpful and responsible one to balance other opinions.
> No, our testing situation is crap, and we need leadership that says more than "not my problem".
No. Testing is crap because developers and employers don't put enough time into testing. They know what has to be done, leadership has told them what has to be done, common sense says what has to be done. They refuse to do it.
When code gets to a pull request for Linus it should have had enough testing (including integration testing via linux-next) that it is ready to be taken up by early user testers via Linus' tree. Distros and ISVs and IHVs and so on need to be testing there if not linux-next.
> Well, he had a point, and you don't want to be artificially injecting fsyncs because for applications that don't need them that gets really expensive. Fsync is really expensive, and it impacts the whole system.
No it was never about fsync, it was about data writes that extend a file hitting persistent storage before inode length metadata write does. By careful reading of posix it may be allowed, as a quality of implementation for actual users (aside from administrator-intensive high end file servers and databases etc from SGI), it is the wrong thing to do. ext3 for example solved it with "ordered" journal mode (not fsync).
You can accept it is poor quality but decide you will do it anyway, but you can't just say it's not a problem because you language-lawyered POSIX and found out its okay, when you have application developers and users complaining about it.
> By way of example, I was in an argument with Linus a month or so ago where he was talking about filesystems that "don't need fsck" (which is blatently impossible), and making "2GB should be enough for anyone" arguments. No one is right all the time, no one has all the answers - but if you go into a conversation assuming the domain experts aren't actually the experts, that's not a recipe for a productive conversation.
I didn't see that so I can't really comment. It does not seem like it provides a counter example to what I wrote. I did not say Linus is never wrong. I have got into many flame wars with him so I would be the last to say he is always right. Domain experts are frequently wrong about their field of expertise too, especially in places where it interacts with things outside their field of expertise.
> I didn't see that so I can't really comment. It does not seem like it provides a counter example to what I wrote. I did not say Linus is never wrong. I have got into many flame wars with him so I would be the last to say he is always right. Domain experts are frequently wrong about their field of expertise too, especially in places where it interacts with things outside their field of expertise.
You came in with an argument to authority, and now you're saying you disagree with that authority yourself, but you trust that authority more than domain experts?
I don't think you've fully thought this through...
Everyone believes what they read in the news, until they see it reporting on something they know about - and then they forget about it a week later and go back to trusting the news.
> You came in with an argument to authority, and now you're saying you disagree with that authority yourself, but you trust that authority more than domain experts?
I wrote what I wrote. I didn't "come in" with the argument to authority though, that was you (or perhaps the OP you replied to first). Anyway, I gave examples where domain experts are myopic or don't actually have the expertise in what other stakeholders (e.g., users) might require.
> Note: Unlike Btrfs and ZFS, the CRC32 checksum only applies to the metadata and not actual data.
https://wiki.archlinux.org/title/XFS
---
bcachefs isn't stable enough to daily drive.
> Nobody sane uses bcachefs and expects it to be stable
—Linus Torvalds (2024)
https://lore.kernel.org/lkml/CAHk-%3Dwj1Oo9-g-yuwWuHQZU8v%3D...