Bcachefs Lands More Fixes Ahead Of Linux 6.7 Stable Debut

[PuckPoltergeist]

Are you stupid? yeah, that's the *entire* xfstests repo, dumbass. Did you mean to say that ext4 sees more attention?

Show me the last time someone made a BTRFS-specific change of any type. Even just to hook up testing of a setting.

Show me the last time BTRFS passed the tests without failures or regressions.

Developer12 in case you missed it sweetheart: https://lore.kernel.org/linux-btrfs/...28014515f823f6

[PuckPoltergeist]

Are you stupid? yeah, that's the *entire* xfstests repo, dumbass. Did you mean to say that ext4 sees more attention?

Show me the last time someone made a BTRFS-specific change of any type. Even just to hook up testing of a setting.

Show me the last time BTRFS passed the tests without failures or regressions.

I was thinking, you're able to read git history when it's presented with a nice GUI. Sorry sweety, my fault

But Quackdoc has already pointed to the relevant facts in the repo of the Btrfs maintainer

[Quackdoc]

Are you stupid? yeah, that's the *entire* xfstests repo, dumbass. Did you mean to say that ext4 sees more attention?

Show me the last time someone made a BTRFS-specific change of any type. Even just to hook up testing of a setting.

Show me the last time BTRFS passed the tests without failures or regressions.

I dunno, seems active enough to me https://github.com/kdave/xfstests/co...er/tests/btrfs is there something else to be looking for?

[Developer12]

Nice try kiddo:

https://github.com/kdave/xfstests/tree/master

Are you stupid? yeah, that's the *entire* xfstests repo, dumbass. Did you mean to say that ext4 sees more attention?

Show me the last time someone made a BTRFS-specific change of any type. Even just to hook up testing of a setting.

Show me the last time BTRFS passed the tests without failures or regressions.

[varikonniemi]

Again, let's return to the discussion once the first instance of confirmed bcachefs bug eating data.

[PuckPoltergeist]

Stale. Looks like the last time there was any BTRF-related activity was 9+ years ago. All of the following activity (the best google could dig up) is from circa 2014:

Nice try kiddo:

https://github.com/kdave/xfstests/tree/master

[Developer12]

As far as I understand this is/was a bug just uncovered more reliable but was there for a long time.

It's been theoretically possible for a long time, but it's never been found because it is absurdly hard to trigger on anything before changes that were made in 2.1.4. Even then, it didn't become very likely until further changes landed in 2.2, and was only actually noticed in the presence of further changes in coreutils' access semantics.

To put things in perspective, this bug has probably taken longer to find than unsoundness in the linux kernel's core arm64 atomic primitives that were found by marcan recently.

Called xfstests (because of the origin) and is run all the time by different developers/CI:

https://kernel.googlesource.com/pub/scm/fs/ext2/xfstests-bld/+/HEAD/Documentation/what-is-xfstests.md

Stale. Looks like the last time there was any BTRF-related activity was 9+ years ago. All of the following activity (the best google could dig up) is from circa 2014:

https://linux-btrfs.vger.kernel.narkive.com/5fTMSU0m/xfs-tests-for-btrfs

https://lwn.net/Articles/613998/

https://patchwork.kernel.org/project/linux-btrfs/patch/[email protected]/

Some time ago, when I was more involved with this (~10years) there were bugreports and posts in forums about damaged filesystems/zpools with the same advice over and over again: Recreate the filesystem and restore the backup. It's not the first time ZFS is eating data.

When people who've lost data to BTRFS within the last few _months_ come out of the woodwork every time it's brought up, I'm going to need to see some receipts for that.
By contrast, the guys from joyent have said on record that they only time they EVER lost a customer's data on ZFS was when someone manually wrote garbage all over actively-running kernel code.

[PuckPoltergeist]

Btw. bcachefs seems so superior, it doesn't need even tests. At least I didn't found them

Have to revert this. Xfstests is covering this too, just no special tests for bcachefs

[PuckPoltergeist]

Called xfstests (because of the origin) and is run all the time by different developers/CI:

https://kernel.googlesource.com/pub/scm/fs/ext2/xfstests-bld/+/HEAD/Documentation/what-is-xfstests.md

Btw. bcachefs seems so superior, it doesn't need even tests. At least I didn't found them

[PuckPoltergeist]

The bug from last month was very difficult to trigger and requires very specific conditions (it only causes programs to read zeroes when reading back recent in-flight writes), and was only very recently found when aggravated by other changes in both ZFS and coreutils. It's a strong testament to ZFS' reliability that we're down to such hard-to-trigger bugs, with this possibly being the first ever to risk actual data corruption.

As far as I understand this is/was a bug just uncovered more reliable but was there for a long time.

It's now been patched, and a whole class of testcases added to the ztest testsuite to catch issues like it in the future. When was the last time someone subjected BTRFS to a comprehensive battery of torture tests, much less hooked it up to CI?

Called xfstests (because of the origin) and is run all the time by different developers/CI:

https://kernel.googlesource.com/pub/scm/fs/ext2/xfstests-bld/+/HEAD/Documentation/what-is-xfstests.md

That might well have been the first time a bug in ZFS could lead to data corruption in it's entire history.

Some time ago, when I was more involved with this (~10years) there were bugreports and posts in forums about damaged filesystems/zpools with the same advice over and over again: Recreate the filesystem and restore the backup. It's not the first time ZFS is eating data.