16 points farlight 53 minutes ago 10 comments

Farmadupe 15 minutes ago | parent

@farlight assuming that you're the creator do you think you'd be able to rework the HTML/CSS? I'm sure you've got good data but speaking on behalf of my eyeballs, the results page is... hard to read!

Farmadupe 11 minutes ago | parent

> 2G of random garbage is written directly onto one member device (behind the filesystem's back, offset 1G — python injector; uutils dd mis-seeks on dm devices), caches dropped, then a full scrub: btrfs scrub -B, zpool scrub + wait, bcachefs scrub, md/lvm sync-action 'check' (which can only COUNT mismatches — no checksums to know which copy is right).

I'm not sure that nuking 2G of the underlying block device is a recoverable error on any filesystem that I'm aware of? Can you confirm if any ofthe filesystems really came out of the other side in a usable state after scrubbing?

-----

> Trivial-op p99, idle (ms) # A trivial operation — one 4k write + fsync every 200ms (like a shell appending history or an editor updating its swap file) — run alone for 10s. p99 of the fsync completion

In fact, if it's OK for me to ask, are any of the metrics tht you used standard industry metrics? It looks like several of the tests are bypassing the kernel's page cache? -- which I worry may fall into the trap of "I modified the system to be unrepresentative of reality and then tested it".

vlovich123 8 minutes ago | parent

1 device out of the replica set I’m assuming so all of them should recover.

skerit 15 minutes ago | parent

Oh, so bcachefs is doing pretty well.

blop 9 minutes ago | parent

For peace of mind I'm still using zfs (since the last 15+ years) but I'm definitely not impressed by the performance...

slyfox125 5 minutes ago | parent

Different tools for different jobs; use ZFS for your data store and ext4 for your primary drive.