I'm not involved in any of this besides watching from the sidelines. But it seems to me that Kent's main focus right now is clearly getting the filesystem into the kernel so that it can get the testing and bugfixing it needs. To the point that his determination is annoying all of the veteran kernel maintainers. (Who, to be fair, have a right to be conservative on what they accept into the kernel as they have been burned many times in the past by not being conservative enough.) Even though I am sure he has grand ideas for the future, he seems to be happy enough with the current state of things but hasn't been successful in attracting outside help on his own. Which is why he is trying to drum up interest on the LKML.

I don't think it's likely that Kent is letting known bugs slide, as that would be extremely detrimental toward getting his patches merged.

I started using btrfs back when it was way less stable, but that instability was more than offset by the other features.

The last time I lost a btrfs filesystem was four years ago when it was less stable, but it did not matter because it only amounted to about an hour of logs lost, and I reconstructed it in minutes. So btrfs is a must on any embedded devices. It frees me to use cheaper media, because I can have two copies of all data and metadata, and compression, and fine grained external snapshots.

Zfs is great for making big complex arrays and if you plan out how your are storing your data ahead of time. But it has a steeper learning curve and is more seperate from the underlying OS.

Btrfs fills this perfect niche for me of being a drop in replacement for ext4, and being really flexible and offering some of the nicer features of zfs. (differential snapshots, checksumming, compression)

So I'm excited to try bachefs as an alternative to btrfs.

This isn't a good sign... Journalling should never, if bug-free, lead to data corruption or loss even if there is a power outage.

And, even if there was some bug, one would expect a robust filesystem to say "ah, there is some data corruption here, so we're gonna run an fsck and recover every single file on the disk except perhaps the one or two that the bug clobbered."

This will thwart any filesystem.

SSDs do not reliably report UNC read errors when data can't be retrieved. Garbage or zeros are returned instead.

There's a reason why ext4 and XFS added journal and metadata checksumming. Storage devices just aren't as reliable at informing the kernel when it suspects the data returned is bad.

Recent but no longer current trees, can be partly overwritten when the kernel is informed a super block write was successful. But if the super block write wasn't successful (the device lied), the stale super block on disk points to damaged metadata and recoverability isn't certain.

If it isn't correct, ignore it and move on to the previous superblock. Keep going until you can verify a contiguous 30 seconds of superblocks.

If writes are being delayed by more than 30 seconds, your problems go beyond "out of order".

This does impose the requirement not to overwrite trees that are only a minute or two old. That should not be hard.