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).
[This comment has been deleted by an automated system]
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.
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.
I’ve had great luck with xfs and zfs, but btrfs has lost data for me more than once.
You should try ZFS (not on the SD, though). It’s pretty solid and used in NAS very often.
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.
