On Fri, Oct 18, 2024 at 05:15:06PM -0700, Carl E. Thompson wrote: > > > On 2024-10-18 12:12 PM PDT Kent Overstreet <[email protected]> > > wrote: > > > ... > > > It sounds like you should go back to ZFS then. > > If you tell me you don't want me testing bcachefs anymore it won't > hurt my feelings and I'll respect your wishes. There are plenty of > quality filesystems for me to use where I'll have less hassle. But I'd > suggest to you that pushing out testers who point out bugs and try to > offer constructive criticism isn't the best way to make quality > software.
Testing is fine. I have a lot of users and testers that I work with, and will bend over backwards for if something is broken, and to make sure data isn't lost. But I do draw a line at being demanding, or all the "constructive criticism" that comes with an attitude of "I know your job better than you do". You wouldn't walk into someone's office and immediately start telling them how to do things, would you? I don't suscribe to the modern theories about how we all have to be nice to each other and always use nice words, if you're legitimately pissed off because I screwed up and shipped something broken and it ate your data and now you're screwed if it's not recovered - that's one thing. Making sure your data is safe is why I'm here, and if you want help with recovering a filesystem, I'll always help with that. But you're complaining about an EOL kernel, where the issues have long been fixed, so in this case there's just not a lot I can do. I could ask Greg to cut a new 6.9 release, but all the distros have been told that 6.9 is EOL so it's not likely it would be widely deployed. > > I have been hearing a lot of people complain about regressions in > > amdgpu. Have you taken that up with them? > > I personally have not because other people already have. They're aware of the > issues and I'm confident they'll fix them. > > > The capability of doing seamless, automatic upgrades and downgrades, to > > the extent that bcachefs can, is something new that other filesystems > > don't have. > > > > And it's been incredibly useful. Without it, rolling out the disk > > accounting rewrite wouldn't have been possible - and that got us per > > snapshot ID accounting, compression type accounting, per-btree > > accounting, and per-inode fragmentation accounting (not all of these are > > exposed to the user yet, but they're there). > > > > While bcachefs is still marked experimental, doing these upgrades > > automatically makes sense because it gets us better test coverage of > > codepaths that will need to be rock solid later, and it drastically > > reduces the amount of compat code I have to carry around. I'm hoping to > > get several more on disk format features done while we're still in the > > experimental phase - for inode allocation improvements, fsck performance > > improvements, and assorted other odds and ends. > > What you say here makes perfect sense. But I also think it's risky. > That's the point I was trying to make. Anyone can build a bridge that doesn't fall down, it takes an engineer to build one that just barely doesn't fall down. There's is always some level of risk to developing new capabilities and deploying new code, and we have to balance those risks against the worth of those capabalities, along with all of our priorities. The ability to upgrade to a new on disk format, and then seamlessly downgrade - that hasn't been done before, keep that in mind, and that's an enormously useful capability that makes it dramatically _less_ risky to deploy new features.
