[demizer]

I've been using it for the last two years and I think it has potential over btrfs, and zfs specifically. I used zfs on my hobby data array for 10 years prior but decided to downsize everything and use bcachefs in the hopes of it one day being in the kernel (unlike zfs).

Device management is super easy, but is still missing knobs and dials for the most part. Multi device fault tolerance also needs work as I have had to recreate a 16tb array twice now due to journal corruption on power outages.

I'll keep using it and reporting bugs, but I do feel the author is letting some bugs slide to focus on getting the fs in the kernel so that it gets more capable users that can provide patches. I am a sophisticated user, but definitely not a kernel developer.

[bityard]

> I do feel the author is letting some bugs slide to focus on getting the fs in the kernel

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.

[koverstreet]

Can you tell me about the journal corruption you were seeing?

[unqueued]

I will probably give bcachefs on one of my machines.

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.

[londons_explore]

> as I have had to recreate a 16tb array twice now due to journal corruption on power outages.

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

[cmurf]

ZFS and Btrfs have demonstrated devices have a variety of transient failures including maintaining write order implied by fsync or fua.

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.

[Dylan16807]

Incorrect write order shouldn't thwart a CoW filesystem. It can check at mount time whether the last few commits are fully there.

[cmurf]

If the write order isn't guaranteed you can get a new super block in place without the updated trees being written. The super points to trees that don't exist.

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.

[Dylan16807]

You can tell if the metadata is correct by checking the hashes of everything committed by that superblock.

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.