I’m using EndeavourOS with ext4 file system for daily usage and a dual bootable Windows for gaming. What I want to have right now is getting rid of Windows completely.
When I tried it before, I had to try multiple tweaks for a game and find which one worked on Linux. Therefore, I want to take a snapshot with BTRFS and try it until I find the right configuration.
While I have quite a bit of experience with Linux, I’ve never used BTRFS. Do you think it’s worth it?
I thought about keeping the games on the ext4 system, but I hate splitting the disk. I’m thinking of keeping the games in a non-snapshot volume.
BTRFS is worth it. It’s a bit faster than ext4. And with BTRFS assistant or snapper, you can configure automatic snapshots of your OS partition. And grub-btrfs will allow to integrate them to the boot menu. Once you are booted via snapshot, there is a way to replace / file system with that snapshot permanently, or you can boot to another one.
And remember, snapshots in BTRFS is just a formal thing, use them only if you specifically need their features, like read only sub volumes. If you just need to backup some directory, for example with steam games, no need to do the actual snapshot. You can easily backup large amount of data with just
cp -dr dir dir_backupno matter how large is it, it will be done immidetelly and without taking additional space.Btrfs is amazing for a steam library. The single best feature is the compression. Games tend to have lot of unoptimized assets which compress really well. Because decompression is typically faster than your disk, it can potentially make games load faster too.
I put a second dedicated nvme drive in my PC just for steam. It’s only 512GB but it holds a surprisingly large library.
I actually found the opposite with my steam library; on ZFS with ZSTD I only saw a ratio of 1.1 for steamapps, not that there’s really any meaningful performance penalty for compressing it.
OK I just measured mine. I have 459GiB of games on the drive, consuming 368GiB of space. That’s about 25% compression. I’m using
compress=zstd:9.I should try deduplication. I have 4 steam users and I’ve created an ACL hell to prevent the same game being downloaded and installed twice.
If you’re messing with ACLs I’m not sure deduplication will help you much; I believe (not much experience with reflinks) the dedup checksum will include the metadata, so changing ACLs might ruin any benefit. Even if you don’t change the ACLs, as soon as somebody updates a game, it’s checksum will change and won’t converge back when everyone else updates.
Even hardlinks preserve the ACL… Maybe symlinks to the folder containing the game’s data, then the symlinks could have different ACLs?
I wrote a blog about it last year with my method of deduplicating. I really need to update that bit because steam keeps writing files that don’t uphold the group permissions, and others get permission errors that need to be fixed by admin. Steam also failed to determine free space on a drive when symlinks were involved.
I even found recently that steam would write files in /tmp/ as one user, and fail when you logged in as another user and tried to write the same file. Multi-user breaks even without messing around.
My current solution doesn’t use symlinks. I just add two libraries for each user. One in their respective home directory, and another shared in /mnt/steam. It means that any user can update a game in /mnt/steam, and it cleanly updates for all users at once.
It depends on what sort of games you play. Some games / genres / publishers are much worse about this than others.
and
my axededuping. all those dlls and wine prefixes that contain them occupy space only once.Is the compression opt-in or is it enabled by default?
You have to enable compression in fstab.
Ah okay, cool. It’s that easy? Does it compress all existing data after that or is it only for new data?
What would I have to do to compress existing data?
It is only for new data.
For example, you would have to defragment your filesystem again with
btrfs filesystem defragment -r -v -czstd /. Wherezstdis an algorithm and/, a root path. With this command, the default compression level will be used, which is level 3.Be careful, defragmenting the btrfs file system will/can duplicate the data.
As for a mount point, if you decided to use zstd algorithm with level 1 compression, just add the
compress=zstd:1orcompress-force=zstd:1to the mount options (fstab or while mounting manually)So I set up my system with btrfs in the last days and I converted two external drives (from ext4) (mainly game) and run defrag and balance, because it was mentioned in a guide to compress the existing files. Was that a bad idea? Didn’t read anything about duplicates.
Reading the manpage (btrfs-filesystem), duplication can happen on some odd kernel versions, so no danger.
If I know correctly, defrag will always duplicate the reflink files.
https://btrfs.readthedocs.io/en/latest/Defragmentation.html
Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.
BTRFS works great across all my drives under Nobara. Same applues when I access these drives from Ubuntu.
Steam also has no issues in my case. Even wine works line Intended.
I’ve always used BTRFS with rolling release distros lije Arch or Tumbleweed and never had an issue with the filesystem.
I’ve been happy with btrfs. No issues with gaming. There’s even a pretty good Windows driver, which I’ve used successfully to transfer data between Linux & Windows. Though I haven’t installed Windows itself to btrfs, which is apparently possible!
Butter is amazing especially on ostree like fedora atomic for example
I use Fedora which defaults to BTRFS and never once had an issue with any game because of it. Your file system shouldn’t matter for gaming at all so long as you stay on Linux native ones and avoid NTFS Windows drives.
My Linux stream library is on Ntfs, for theoretical compatibility purposes with Windows which I never boot any more anyway, but generally I have had zero problems apart from an issue with Dota 2 a few years ago where I had to symlink some folder. But I don’t think think it is needed anymore.
Good to know the situation with cross compatibility has improved! I just saw enough posts of people having issues with a shared Windows/Linux NTFS drive over the years to advice against that setup.
Isn’t arch-chroot a bit different in btrfs?
I think you mean having to mount the subvolumes instead of the partition itself.
This can be done by mount -o subvol=whatever /btrfspartition /mountpoint
After having done that it’s the same.
I don’t know? It’s been a long time since I used Arch, and besides OP is using EndeavourOS so it won’t matter.
EndeavourOS is Arch-based and I’m pretty sure it also uses arch-chroot.
Yeah but when is that gonna matter? It uses a graphical installer so you won’t need to touch the arch-chroot command at all. And if for some reason you do, the Arch wiki is there for you.
Sure, I had chosen ext4 because it was unnecessary complicated with btrfs and I don’t do snapshots (all my data is in my private cloud, so I don’t loose data if I reinstall my linux)
Great, good for you. But what’s your point? OP explicitly said they have a specific use case for BTRFS and just wanted to know if there are any specific issues related to gaming with it. arch-chroot being slightly different with that filesystem is not an issue for 99% of EndeavourOS users.
Lol, OK, just wanted to point out the difference I approached, no need to feel attacked, damn…
This. I’ve not had any issues across my laptop or desktop.
I was worried about the possible high overhead of CoW in BTRFS. I guess it won’t cause much of a problem. Thank you 🙏
Unless you’re making hundreds of snapshots with massive changes between each it won’t matter. It might matter if you plan to use spinning rust as your main drive, but I imagine you’ll be using an SSD.
iirc Garuda Linux defaults to it, and is gaming focused distro of arch. Whether its worth it is up to you, but there are already users who daily drive it that way.
