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
It should perhaps be noted that whole btrfs is pretty stable overall, I’ve run into two cases where deduplication corrupted the file system. I couldn’t get the files repaired either, they were just screwed up.
This could’ve been because of a simply bit flip, and the files were just temp files anyway, but it’s probably good to know about the risk before turning it on.
For something like a games console where you can just download the games again it’s probably fine regardless, but if you care you could use this knowledge to only use such features on SD cards to make sure the system is still bootable.
The filesystem metadata comes with 2 copies that can heal each other, and Copy-on-Write protects against power loss. The filesystem itself should be bulletproof.
I feel like people reporting data loss on BTRFS are unaware that at least BTRFS is actually measuring the data loss. Bitrot is not rare, especially with how big our drives are getting. If you care about your data it should be backed up and/or RAIDed. Ext4 has no idea if your data is still intact - that’s not the same as no data loss.
It should be, but neither files were damaged before the dedup attempt. I went balance-check-dedup-check-balance on purpose to make sure I wouldn’t accidentally deduplicate with a damaged extent. I don’t know if the metadata was damaged or the extent itself, but there were checksum failures on two specific extents in two sets of files that got deduplicated (4 files in total, both sets of temporary files in the Lutris cache).
I’m not mad or anything, and I accept a few kilobytes of lost data every now and then. There’s a reason I have (signed, encrypted, diffed) backups in the first place! That doesn’t change the fact that there still are a few edge cases where BTRFS suffers corruption under heavy load with a wide range of features in use (many of which don’t even exist in other file systems, I myself am quite fond of CoW+deduplication of existing files+compression on selected paths+snapshots every time I run apt upgrade). If we all pretend these edge cases never happen, they’ll never get fixed.
If this happened enough for me to be able to replicate the problem, I would’ve filed a bug report. I’m happily using btrfs on my desktop drives drives and I’m planning on converting my laptop as soon as I can get enough space for a full backup just in case. There’s no doubt BTRFS is superior to ext4, and even ZFS has issues BTRFS doesn’t have (no dumb Oracle licensing issues, for one).
For something like a Steam Deck SD card, BTRFS is a no-brainer. I’m a little annoyed that I need to mount the SD card manually if it’s not ext4, but the space savings and improved loading times are worth it.
What deduplication program did you use? Deduplication is not technically an end-to-end supported feature, and depending on how the third-party program implemented it there could be issues earlier in the pipeline. I’m also not sure how a RAM bit flip would interact in this scenario - I know ZFS checks the file checksum several times during transaction but I don’t know how often BTRFS does.
The problem is that there are a lot of people online reporting vague problems with BTRFS, but all reports have little info on how they were actually caused and are not able to be reproduced. There is no solution if we’re operating under these rules, other than to completely stop using BTRFS out of pure superstition. If there are bugs we need to be able to point to the bugs in order to fix them. As I said before, this problem you had would not have even been detected by Ext4, so I think error reporting is biased against a FS that actually checks its work. W/r/t to checking work, I think ZFS gets away with a lot more because it’s normally run in RAID setups, where healing happens automatically. BTRFS, lacking RAID5/6 support, is usually just run on a single drive, and any data integrity error becomes a target of frustration as soon as it happens.
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.
anlumo@feddit.de 1 year ago
Yeah, Linus Torvalds has been pushing for ECC RAM everywhere for just this reason.