Steam on Linux can not validate data on ZFS filesystem

[orivej]

When Steam library directory is stored on a ZFS filesystem (mounted with zfsonlinux in-kernel drivers), revalidating game data (Game properties -> Local files -> Verify integrity of game cache) immediately declares all files invalid without checking and proceeds to redownload them again.

[orivej]

I tried moving Steam library to an ext4 filesystem, then revalidation worked; I moved it back, and the erroneous behaviour reinstated. Apart from this manual revalidation issue Steam works fine on ZFS, except that maybe Steam beta updates itself too often, but I switched back to stable and do not have conclusive evidence.

By "move" I mean sudo mv ~/.local/share/Steam /; ln -s /Steam ~/.local/share/Steam. I experimented with two different ZFS partitions and one ext4 root.

[johndrinkwater]

When it did work for you on ext4, was that using a symlink for ~/.local/share/Steam?

[orivej]

Yes, the command above moved from ZFS home to ext4 root and symlinked it back. (However, Steam client resolves the symlink, so that in Settings > Downloads > Steam Library Folders it then said "/Steam". To move from ext4 to the second ZFS partition I had to do sudo mv /Steam /data/games/; ln -s /data/games/Steam /Steam; ln -sf /data/games/Steam ~/.local/share/Steam; then after starting Steam once I could remove "/Steam" since the client already resolved it.)

P.S. I am on beta channel and Steam client does not download updates more often than they come out. So the problem only affects manual verification of game data.

[mk0x9]

Same for me. Manual verification of Cave Story failed for all files, steam re-downloads them.

Using ZFS on all hard drives and partitions.

[sir-maniac]

This may be related, I have the same symptoms mounting an ntfs partition(using ntfs-3g in /etc/fstab).

A symbolic link to ext3/4 verifies the files properly, but when on ntfs, all files are invalidated and re-downloaded.

I used World of Goo to test with, but this also seemed to interfere with the installation of X3: Albion Prelude, which uses many of the same files of X3:Terran Conflict, and would invalidate them prior to installing X3AP on top of X3TC.

I mounted the partition with ntfs-3g as instructed in the knowledgebase article, I tested it with the exact options specified. (https://support.steampowered.com/kb_article.php?ref=7611-FHLZ-4319)

[hellmind]

Damn still not fixed?, I'm having the same issue but with SteamCMD isn't any fix or tweak to avoid this?

[TheSkorm]

I just hit this bug as well. Reverted the files from snapshots and all worked again.

NAME  PROPERTY              VALUE                  SOURCE
tank  type                  filesystem             -
tank  creation              Sat Aug  2  7:10 2014  -
tank  used                  5.27T                  -
tank  available             1.86T                  -
tank  referenced            5.23T                  -
tank  compressratio         1.00x                  -
tank  mounted               yes                    -
tank  quota                 none                   default
tank  reservation           none                   default
tank  recordsize            128K                   default
tank  mountpoint            /tank                  default
tank  sharenfs              on                     local
tank  checksum              on                     default
tank  compression           off                    default
tank  atime                 off                    local
tank  devices               on                     default
tank  exec                  on                     default
tank  setuid                on                     default
tank  readonly              off                    default
tank  zoned                 off                    default
tank  snapdir               hidden                 default
tank  aclinherit            restricted             default
tank  canmount              on                     default
tank  xattr                 on                     default
tank  copies                1                      default
tank  version               5                      -
tank  utf8only              off                    -
tank  normalization         none                   -
tank  casesensitivity       sensitive              -
tank  vscan                 off                    default
tank  nbmand                off                    default
tank  sharesmb              on                     local
tank  refquota              none                   default
tank  refreservation        none                   default
tank  primarycache          all                    default
tank  secondarycache        all                    default
tank  usedbysnapshots       45.4G                  -
tank  usedbydataset         5.23T                  -
tank  usedbychildren        107M                   -
tank  usedbyrefreservation  0                      -
tank  logbias               latency                default
tank  dedup                 off                    default
tank  mlslabel              none                   default
tank  sync                  standard               default
tank  refcompressratio      1.00x                  -
tank  written               0                      -
tank  logicalused           5.27T                  -
tank  logicalreferenced     5.23T                  -
tank  snapdev               hidden                 default
tank  acltype               off                    default
tank  context               none                   default
tank  fscontext             none                   default
tank  defcontext            none                   default
tank  rootcontext           none                   default
tank  relatime              off                    default

[prometheanfire]

what do you mean you reverted? Just so you didn't have to redownload them?

[TheSkorm]

Yup restored from snapshot so i didn't have to download again

[prometheanfire]

Well, looks like o_direct may get into ZoL in 0.6.5 now and hopefully 'soon'. This seems to be the source of the problem.

[craig-sanders]

looks like O_DIRECT has been bumped to the zfsonlinux 0.70 milestone on 2015-07-17 https://github.com/zfsonlinux/zfs/issues/2872#issuecomment-74795421

FYI, I just tested this with Papers, Please on ZFS v0.6.5.2 - all files failed to validate and were re-downloaded. I'd hate to have that happen with 40+GB of Middle Earth: Shadow of Mordor.

is there any movement on this issue on the Steam side?

A "quick and dirty fix" would be to check if O_DIRECT is supported and disable validation (or at least pop up a warning and confirmation dialog box) if it isn't.

[Seegras]

Don't use O_DIRECT. It does NOT have a performance advantage. Use posix_fadvise() to avoid caching large file-checks.

[gdrewb-valve]

Same as #2515, the latest Steam client beta should fix this.

[Spice-King]

Looks fine to me. After following directions on https://wiki.ubuntu.com/Kernel/Reference/ZFS on my Ubuntu 15.10 laptop (same system as over here), I've made a ZFS pool and filesystem with a 8GB USB stick that was already empty.

Moved the files on to ZFS and symlinked ~/.local/share/Steam to /test-steam/library/Steam. Took a while to install the ZFS kernel module, but it's working fine for me. VVVVVV and Papers, Please both validate just fine, even when I enabled ZFS compression while poking around.

Much like #2515, I'm feeling that this is a closed case.

[prometheanfire]

cool, tested here, verified all my games steam package version 1452297105

[JoshuaMurphynz]

Sweet as feel free to close this On 10 Jan 2016 09:44, "Matthew Thode" notifications@github.com wrote:

cool, tested here, verified all my games steam package version 1452297105

— Reply to this email directly or view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/2533#issuecomment-170279743 .

[gdrewb-valve]

Thanks, closing.