I dont have the same experience. I have XFS on /home but the libraries themselves are on an EXT4 partition. I haven't had any problem with the client itself

I have no problems with ZFS as my $HOME. getfattr -dR ~/.local/share/Steam shows that some Proton-related files use extended attributes. Maybe your system has extended attribute support disabled on XFS.

@stratus-ss my library was on the XFS partition. @ryao sounds plausible, but as the problem went away on switching to btrfs I never checked that. Hopefully, someone else with the problem appears and can confirm.

I would imagine @ryao is correct - lack of extended attribute support has been the culprit in a few edge base bugs seen in the WINE community as well. AFAICT btrfs has xattrs on by default.

No, this isn't extended attribute support, which XFS has had for longer than ext*. It's 64-bit inodes used for the files in the FS and 32-bit applications trying to stat() them, and failing because their buffer isn't big enough to hold the inode value.

TL;DR On kernel 3.7 and higher, XFS defaults to creating inode numbers using 64 bits for new files. 32-bit software not built with the LFS define will get confused when stat()ing such files, usually ending in crashes/missing UI pieces, etc.
Workaround for file creation: mount -o remount,inode32 /xfs/mount # and add inode32 to /xfs/mount in /etc/fstab
Workaround for existing files (after enabling inode32 for file creation): cp -a /xfs/mount/dir /xfs/mount/newdir && mv /xfs/mount/dir /xfs/mount/olddir && mv /xfs/mount/newdir /xfs/mount/dir # you can then rm -rf olddir

Note that you really need to copy everything on the xfs FS if it has any of the OS on it, too. freetype, for example, will stat() every directory on the way to your fonts, as well as all the font files themselves.

So, in 1996, Unix vendors had a series of meetings known as the Large File Summit (http://www.unix.org/version2/whatsnew/lfs.htm)l, for addressing files larger than 32-bits in size on the existing 32-bit operating systems. They came up with a set of extensions that allows file system internal values to be 64-bit. This included the file size, but also included other filesystem metadata, like the inode number. This was also implemented in glibc, which is the libc used by Linux.

XFS in Linux has had two mount options related to inode number allocation for new files: inode64 in kernels before 3.7, and inode32 in kernel 3.7 and beyond. inode64 enabled allocation of 64-bit inodes on kernels where 32-bit inode allocation was the default. inode32 enables allocation of 32-bit inodes on kernels where 64-bit inode allocation is the default.

When the non LFS stat() system call in 32-bit glibc runs into a 64-bit inode, it returns an error to the calling application. There's not much the calling application could do to workaround the problem by handling the error, other than to ignore whatever reason it was calling stat() for in the first place. So most of them don't, and end up failing horribly.

Many games still build for 32-bit targets, which means they get 32-bit libraries that can't deal with the default XFS inode allocations. Additionally, as most Linux users are running 64-bit operating systems with native 64-bit filesystem metadata support these days, LFS support isn't needed there anymore. As distros have focused on the 64-bit targets where the users are, 32-bit LFS support has suffered, largely through people not realizing it is still needed today for running 32-bit things.

Proton runs fine for me on all my xfs filesystems, but they're all mounted with inode32 (and every file has been copied out of a 64-bit inode number into a 32-bit inode number), mostly because of the 32-bit steam client and steam games that are 32-bit and not built with LFS support.

Building with LFS support is as easy as adding a -D_FILE_OFFSET_BITS=64 option to the cflags when compiling all the C libraries and the application itself: https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html

@neuro42 If I recall correctly, it is possible to compile the XFS driver without support for extended attributes. It is also possible to mount a XFS filesystem with support for extended attributes disabled at runtime.

That said, your inode number explanation makes sense. It might not make sense on the surface given that ZFS also has 64-bit inode numbers, but I can clear that up by saying that it prefers low numbered inode numbers. This avoids the issue unless you make more than 2^32 files, which forces it to use numbers from the 64-bit address space. I am not sure what the inode32 workaround does when you try to create more than 2^32 files on XFS, but I am happy to not worry about what happens to Proton when someone's home directory has more than 2^32 files. Users with that problem can always make a dedicated mountpoint for Steam.

@ryao There isn't a configuration option for it in recent kernel trees I have, only for POSIX ACLs. The xfs(5) man page also only lists options to switch between two methods of writing inline xattrs to disk; I don't see anything to actually disable them at compile time or run time.

XFS will report ENOSPACE errors if an inode needs to be created and there are no available 32-bit inodes available with the inode32 mount option.

I'm having the same issue.

Attempting to run something via Proton/SteamPlay causes the Steam client to crash.
I initially thought it was because I don't have Vulkan set up (I'm running an AMD HD7950 with the radeon driver). I had planned to try the amdgpu driver, so I would have Vulkan support, the next time I upgrade Tumbleweed (in a few weeks once LLVM7 and Mesa 18.2 are fully released and merged into Tumbleweed).

Using XFS with attr2 and inode64 enabled (pretty sure those have been the defaults for over a decade).

I've been dealing with 64-bit inode bugs for a long time. Mainly in games, but I remember having to use a workaround (symlinking the file/directory to another drive with 32-bit inodes) to run Adobe Acrobat Reader (back when that was still a thing).
I feel like the Steam client had one when it was originally released.

If I have the time, I'll mess around with symlinking and see if it clears up the issue.