Btrfs is a filesystem (like FAT, NTFS, and ext4), but has some distinct advantages:
-
Increased storage - thanks to compression and file deduplication, Btrfs can save you considerable amounts of storage. I have 517G of files on my Deck’s SSD, but it only uses up 410G of storage to hold those files. Compressing your filesystem can also shorten load times, especially for slower memory devices like the SD card.
-
Snapshotting - save snapshots of the file system and easily roll back if there’s a problem.
Converting to Btrfs is easy to do, and doesn’t require having you to resetup/reconfigure your deck. The linked gitlab project will do the conversion, keep all your existing files and settings, and set all the Btrfs configurations for you. The file conversion will persist through updates, and it will setup automatic deduplication of files on the drive. It also allows the Deck to automatically mount Btrfs converted SD cards, and to format new cards in the same format.
Only potential downside I know of is that Btrfs is case sensitive, where the default ext4 on the Deck uses casefolding. Basically this means that Btrfs will treat File.txt and file.txt as two different files. I’ve never run into any issues with this, but I’ve heard it can cause issues with some specific mods that inconsistently capitalize their files. There’s also always some risk whenever you make dramatic changes to your filesystem, but I haven’t really heard of anyone having problems with this. You do have to make sure you have at least 10-20% of your storage free (and a min of 10-20GB free for smaller drives) to make sure it has room for the conversion.
Overall I’ve been using Btrfs for over 6+ months on my deck, and it’s been great. I highly recommend it. I’m not an expert on it, but I’ll do my best to answer any questions on it.
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-checkvsfsck, 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 afsckat all!). Because Ext4 is not Copy-On-Write, it’s highly vulnerable to powerloss events, and anfsckis 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 offsckis repairing the filesystem, which BTRFS and ZFS do throughscruband/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 checkis not something that should be used lightly, and I’ve seen a lot of people just runbtrfs-check --repairexpecting the same behavior asfsck, then wonder why they ended up with a broken filesystem.