Comment

Comment on [PSA] Swapping your Deck's filesystem to Btrfs is easy to do, and can give you more space for free

skullgiver@popplesburger.hilciferous.nl ⁨1⁩ ⁨year⁩ ago

I used duperemove which uses the FIDEDUPERANGE ioctl.

My biggest issues with BTRFS is that the tooling isn’t complete yet. On ext4 a wide range of issues can be fixed with fsck (including fixing broken metadata) while the btrfs check documentation basically tells you:

       Warning
      Do not use --repair unless you are advised to do so by a
      developer or an experienced user, and then only after having
      accepted that no fsck successfully repair all types of
      filesystem corruption. Eg. some other software or hardware
      bugs can fatally damage a volume.

It’s a bit like Windows: it works while it works, it can do some great tricks, but when it breaks and the automagic recovery doesn’t help, you’re kind of screwed.

I feel you, most people with BTRFS issues have hardware issues and are hit by Intel/AMD making ECC memory an expensive feature. But in my specific case, the files actually got messed up because of a dedup gone wrong.

source

Sort:hotnew top

yote_zip@pawb.social ⁨1⁩ ⁨year⁩ ago
I’m interested to see that reported somewhere - the duperemove repo might be a good starting point as that’s generally the standard BTRFS dedupe solution. I don’t currently see any issues on the GitHub repo about corruption (or at least the last one was 7 years ago). Again, I’m not sure if a RAM bit flip could cause this during a dedupe. Just because you scrubbed, deduped, and scrubbed again doesn’t mean there wasn’t a bit flip during the dedupe.

As for btrfs-check vs fsck, there are just way fewer things that need to be repaired in BTRFS and ZFS because they are copy-on-write (ZFS doesn’t even have a fsck at all!). Because Ext4 is not Copy-On-Write, it’s highly vulnerable to powerloss events, and an fsck is required to replay the journal when this happens. BTRFS and ZFS make atomic COW transactions and will never be in a state of corruption on power loss. The other part of fsck is repairing the filesystem, which BTRFS and ZFS do through scrub and/or auto-heal on read instead. ZFS and BTRFS keep multiple copies of the filesystem metadata so that it can auto-repair itself while online. btrfs check is not something that should be used lightly, and I’ve seen a lot of people just run btrfs-check --repair expecting the same behavior as fsck, then wonder why they ended up with a broken filesystem.

source