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