> 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 stab

> 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.