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.
Maybe I used it too early, dunno.
How exactly did the data get lost? Nowadays BTRFS stores 2 copies of its metadata by default (this wasn’t always the case), and since it’s Copy-On-Write (no corruption during power loss) it should be basically bulletproof for filesystem integrity. Running RAID5/6 (which are known to have bugs) or trying to perform filesystem repair without reading the manual is about the only thing I can think of that could cause actual issues.
Scrubs need to be run ~monthly to detect bitrot for normal data. Note that BTRFS actually has checksums for data so you can detect data loss - with something like Ext4 you can only detect if the metadata/filesystem is corrupt. Bitrot happens naturally and should be protected against with either backups or RAID. SnapRAID is a good replacements for RAID5/6 if you’re trying to run BTRFS on a NAS, or you can easily run two drives in RAID1 so they self-heal each other. If data integrity is of utmost importance and you only have one drive, you can actually run
btrfs balance start -dconvert=dup /path/to/btrfs/mountto tell BTRFS to keep 2 copies of your data on your drive, halving total available space and write speed.-mconvert=dupis used to keep two copies of metadata, but that’s already enabled by default.I couldn’t say how, when I got to that point, my goal was recovery, and stabilizing, and moving on. Trying to figure out how it failed was beyond my capabilities and scope