Hello @fallenguru, without knowing the internals of Steam, this issue is probably avoided while retaining your backup strategy by putting ~/.steam/steam/steamapps on the bulk partition instead of ~/.steam/steam/steamapps/common. I expect that would make the Steam Library be on the same partition and no longer crossing an unexpected filesystem boundry between steamapps/common and steamapps/downloading.
Thank you. I suppose I could change the setup.
The reason that I didn't do it like that originally is that that would put compatdata on the bulk subvolume, and the Proton prefixes often have "important" data, like saves (and they don't take up any space anyway, or rather, they deduplicate really well).
Anyway, it's not critical, but I think it's the kind of bug that rears its ugly head in all kinds of places sooner or later, if one doesn't squash it. That, and it did work.
(My long-term dream is that you change the directory structure to something that's a little easier to work with. Not just for backups, also sharing Steam library data between user accounts and computers. ^^)
Just a heads up, it is now impossible to install Proton Experimental with this setup, not even to the second library that's all on a single volume. Unfortunately the terminal output has nothing -- is there some way to generate an useful log?
This may shed some light:
perl -ne 'use POSIX; print $_, "errno $1 = ", strerror($1),"\n" if $_ =~ /errno: ([[:digit:]]+)/' </path/to/Steam/logs/content_log.txt
The perl snippet doesn't produce any output.
On the other hand I've since managed to install Proton Experimental again, not that I can tell you how, I just tried now and again, in both libraries [the one spanning across btrfs subvolume and the "normal" one], and one day it went through [on the "normal" library].
Something is definitely off, but I don't know what. In CK3's case it was definitely moving files across subvolume boundaries that failed, but that had terminal output; there's none for PE, so it may be two different problems, the "disk write error" message is certainly vague enough. I don't own CK3, so I can't re-test that (it was a free weekend).
I'll update this if and when it bites me again; until then please treat it as a wishlist item:
If significant headway has been made in these areas since the original report, feel free to close, I can always make a new report if need be.
proton experimentalx3 2021-08
Your system information
Please describe your issue in as much detail as possible:
I have
/home, including~/.steamas one btrfs subvolume, but~/.steam/steam/steamapps/commonis a separate (nested) one, to allow for different snapshotting and backup strategies. (As a matter of fact, the latter volume is excluded from all such measures, as that's the bulk of the data, and it's easily re-downloaded in case of failure.)Yes, it's a weird setup, but the layout of the Steam folder doesn't exactly make it easy. Anyway, I've been running like this for close to two years now, not one problem, so I consider this a regression.
Recently -- I first noticed when Crusader Kings 3 had a free weekend a while back -- I've been getting "disk write error" at the end of an install or update attempt for some apps ... I remember CK3, and just now Proton Experimental.
When I looked into this for CK3, it seemed to have trouble moving the files from the temporary location they first went to, to the final one under
~/.steam/steam/steamapps/common. Perhaps it's using a rename-style operation that does not work across fs boundaries? (If so, setups using [bind] mounts, symlinks to other fs are likely affected as well.)No terminal output for the failing PE update sadly.
Workaround: re-install affected app to another library that is all on one subvolume (worked for CK3, PE untested).