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.
As someone who fell for the “Swap over to Fat32 and you’ll gain so much space” back in the day, I feel like I need to point out to newbies here, anything done to your file system has quite a bit of risk. Things can go wrong in a way that are unrecoverable unless you full reset your device. I’m not saying this project is unstable, but there is a high amount of risk involved with this.
If you decide to do this, back up all data that you may need saved and then mentally prepare that you may ultimately end up resetting your device in the end. These are real possibilities when messing with file systems.
The real risk is losing a bit of time with this. Since everything is backed up anyways, the data is just a restore away.
If you don’t have a backup, that’s the risk and has nothing to do with this procedure.
For the Steamdeck the risk is even less, since Steam backs up savegames automatically and the games can be re-downloaded at any point for free (except for Unity developers, who have to pay 20 cents for this).
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.
Yeah, Linus Torvalds has been pushing for ECC RAM everywhere for just this reason.
I know this gitlab project sets some downloading/temp folders to have COW disabled, possibly for this very reason.
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
FIDEDUPERANGEioctl.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 checkdocumentation 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.
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.
I noticed this guide recommends
compress-force=zstd, which sets the ZSTD compression to level 3. There’s a BTRFS benchmark and ZFS benchmark of the ZSTD levels which can give a rough idea of how ZSTD performs for transparent filesystem compression. Note that almost all of ZSTD’s compression gains happen starting at level 1, and levels after that have very minor improvements.Also keep in mind that ZSTD levels only affect how long it takes to write new data to the filesystem. ZSTD is somewhat unique as a compression algorithm in that as you increase compression effort, the decompression effort stays the same. You could compress everything with level 15 and it will decompress just as fast as level 1 (~generally). Setting higher ZSTD levels could arguably make more sense for a gaming drive because the data is usually write-once, read-many. I don’t know at what level the Steam Deck CPU will start limiting your I/O though.
BTRFS compression is enabled per-file, so you can change ZSTD levels at any time and old data will still be compressed with your previous algorithm. To recompress using a new level, change your
/etc/fstab/ZSTD level and remount the partition, then run a defrag to poke the data into recompression.Here’s one sharp edge: defrag will unshare file contents so sometimes it’s not just feasible to do it.
Run
duperemoveon the partition after defragging to get those reflinks back. Duperemove is usually a good idea anyway unless you’re running on a HDD - reflinks are almost identical to fragmentation in nature so you might prefer to have less fragmentation on a mechanical drive instead of easy de-duping.If you can do that, you already had enough space for reflinking not to matter in the first place, right? Or you can carefully do defragmenting in parts, running dupremove incrementally? seems like a lot of wasted time :).
Free storage is free storage, and storage is at a premium on the Steam Deck - I would gladly trade time for storage, considering that time passes regardless. This defrag scenario would only happen if you want to change ZSTD levels, so if you pick your level at the start, copy your data on, then run
duperemoveyou’ll save the most space possible without needing to defrag. Deduplication is probably the difference between being able to fit 1-2 more games on your Steam Deck - Wine prefixes are prime targets for deduplication.
I’ve tried btrfs twice, and both times I regretted it. I also regret XFS, and reiserfs, but I had to do that because ext2 could just not deal with the very large, deep and multitudinous number of files I had to manage. Oh and jfs, also regret.
Really? I have run BTRFS for that last 3 years on my desktop and my laptop and it has saved me quite a few times now and I have yet to have any issues tied back to my filesystem.
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
You should try ZFS (not on the SD, though). It’s pretty solid and used in NAS very often.
I’ve had great luck with xfs and zfs, but btrfs has lost data for me more than once.
Compressing your filesystem can also shorten load times
At the cost of adding pressure to the already limited CPU.
To get around the case folding issue you could mount your steamapps/common folder as a loop device with ext4 with case folding support. The virtual device should follow the compression settings without too much issue but deduplication won’t be an option and snapshots may be larger.
I’m a big fan of BTRFS, I use it in my desktop and laptop but I’d be curious if the compression is worth the battery & compute trade off. I’m not sure how much battery/compute is used day to day to decompress and compress files read and written. But I guess it depends on which is more valuable, battery or storage.
