Btrfs is probably not ideal for use with Steam. The filesystem does CoW (Copy on Write) operations so a 70GB library would require extensive time and writes to move/delete.
The file system where Steam resides and functions would probably be much faster if used on an ext4 file system.
Thanks for your tip! When I format again, I will consider.
But… Before update to Fedora 43, I was possible to do this operations by not leaving all operation system very freeze.
Hm… Can you recommend me a way to get a log of this? Idk if it’s gnome thing. gnome-shell and gvfsd-metadata have some CPU usage when it’s is happening .
iotop or iostat will generate logs for you, given suitable flags.
Do you see these issues when moving many files, or only when moving large files? I’ve just copied my entire user directory containing bottles, steam and large numbers of cache files from one directory to another (on the same drive) and I can’t replicate any form of stuttering, slow-down, hang-ups, stalling or anything else that would give me any indication that the nvme drives were busy, which they certainly were.
I copied and deleted a 60 GB game directory, and nothing happens. The operation was instantly finished.
I tried to move a game using Steam, and the operation take a relative longe time but making whole system bad to use (like a Windows PC with 100% HDD being used).
So I got:
Or Steam is really bad optimized to deal with btrfs;
Maybe I don’t realized before that it’s only happening in Steam, and not with general files operation;
A update that I have done before post here fixed the issue.
nothing was copied only reflinked. cp --reflink see man cp
No idea what steam is doing. You can try to experiment with chattr and disable COW (CopyOnWrite) for the whole Steam Library. Create a new directory and set NODATACOW. Then copy (not move) the content of your Steam Library into this new directory.
you can also check the enabled atrributes (compression?) for your steam library lsattr -R /path/to/steam_library
I used Nautilus, but make sense, it was too fast lol.
I should add NODATACOW only to Steam Library directory, or their directory and all their files inside? (I’m not advanced, but I want to test it).
For what I’m seeing here, all files don’t have any attribute, but some have m (which means compression). But my Steam Library subvol (yes, my steam library is a separated subvol) have compression enabled on /etc/fstab:
it does not work for existing files. That’s the reason why you have to create a new dir and copy files from old to new. chattr +C empty_dir is applied to new files and directories created in empty_dir/.
Or you first move the files outside of olddir, then chattr +C olddir and then copy (not move) back to olddir.
unfortunately it’s not possible yet to add nodatacow to mount options for a subvolume. man 5 btrfs
What triggers the delays in Steam? Updating some games, or verifying data? Or does it happen everytime you do something in steam client?
I would expect more users to complain if this were a common problem.
I also tried to duplicate copied Steam library inside NOCOWDATA directory, and copy was instantly done, but I noticed compute was not that fast (it’s was usable this time, but noticeable slower than normal), but SSD was not 100% usage again. Idk if it’s normal too.
By what I noticed, just when move a game to another library (is the same SSD, but in different library. Both in /home).
