Shared Win/Linux drives for Steam?

Yup, it's been done to death, but I still haven't found something stable for myself.

Background:

My desktop PC runs Arch, and has an Ext4 Partition with my Steam Library shared using NFS.

My VM's (Including Garuda and Win 11 with GPU, Soundcard, NIC passed through) have access to the NFS share using a private host/guest network for Steam to share the library. All is working great, with no corruption because the host with NFS is managing the filesystem. Perfect.

My laptop is dual boot Win10 and Garuda, so I can't use the same setup (yet).

I've tried NTFS and BTRFS (Using WinBTRFS) for the shared drive, but often end up with a mangled BTRFS partition that ends up mounted RO, or an NTFS partition with the dirty bit set when I boot Garuda again. That said, I haven't tried NTFS again since the Paragon driver was included in the kernel. I've trawed the net for months with no good answer yet.

Has anyone found a good solution to this, that is actually stable?

I read through this a couple times because it is unclear what the obstacle is. Are you trying to create a drive on your laptop that Windows and Garuda can share?

If so, try ext4. There is a driver available for Windows here. I have no idea how well it works, but it's gotta be better than getting NTFS to work on Linux. :joy:

3 Likes

I've been using winbtrfs and it works just fine (and also available via Chocolatey).

You have to watch whether you install the Windows or Linux version of a game (otherwise you end up re-downloading the data when you launch Steam in the "wrong" OS), but otherwise it's transparent. (Ideally, have a shared area/library for Windows games and a Linux-only library for Linux-native games.)

You also benefit massively from btrfs compression, just make sure you set the correct CompressForce option in the registry and match the compression method and level between the two OS.

3 Likes

Just curious, but as someone that doesn't game on their laptop but also has windows, linux and that winbtrfs driver, would you recommend this compression level you stated for the registry for someone like me? Or this is just for gaming generally?

Yep. Mostly for Steam, but also .torrents, Downloads, and data.

I'll give that link a try, though I seem to remember issues with using ext on Windows, but it was some time ago. Maybe things have improved! Thanks :slight_smile:

That's the one i've been using, via Choclatey.

It's usually under Linux that I install most stuff on Steam anyway. Steam has really improved upon downloading things that are already present, so I've hardly had that issue for a long time.

I'll look up the compression option, but unless I can get a setup running without corruption, I think that will likely make it harder to recover data when/if I need to.

Still, if other people are having no major issues, then maybe it's just a problem with my system. Or me! Thanks

I would recommend enabling compression on any filesystem that supports it. Less data being written to disk, less data needing to be read from disk means both higher IO and less impact on SSD lifespan.

The specific compression level will be personal preference. On my systems I force a high compression (zstd-15) but I have a fast CPU, don't write all that much to disk that frequently, and am happy to wait for the compression to happen when doing larger writes (e.g. during package updates). Lower levels of compression can provide a better balance between compression ratio and compression speed, depending on your use-case, system, and preferences.

5 Likes

Hopefully you have better results than I did. I first tried using NTFS with steam to just use my gaming storage drive from Windows in Linux, but couldn't get that to work for the life of me. I ended up just splitting the drive half btrfs and half ntfs. I tried using winbtrfs and just sharing my btrfs drives with Windows for when I would reboot into it for the odd thing I "needed" windows for, but started having issues with BSODs from the btrfs driver and no longer boot Windows. My progression has gone like this:

  1. I can't fully commit to Linux, I dont know how much it will work for me. I'll try and use as much of my windows setup as possible.
  2. I can't get some of this windows stuff to work in Linux so I'll partition some more storage for Linux and duplicate some data to try this out natively.
  3. Well, this stuff works fine so far on btrfs but a game or two performs kinda poorly or isn't supported by proton fully, maybe i'll try using the btrfs drive on Windows.
  4. Well my Windows installation feels like garbage after being used to Linux and I remember now what a BSOD is... I'll give Linux all the space it needs and only reserve some for Windows.
  5. Why do I have this other 1 TB NVME drive for Windows when I dont boot into anymore?
1 Like

If it was general data, i'd probably use compression. But this drive is purely for games, and most of the large files are already compressed by the games developers, using compression that is judged to be the best compromise between data throughput, and cpu load to give an optimal experience for the game. Adding a 2nd layer of compression might tie up the cpu needlessly for little/no gain, and introduce longer load times, and/or stuttering.

The Paragon NTFS driver has caused some NTFS drives to not be able to mount recently. Users affected by this have needed to revert to ntfs-3g to mount NTFS drives successfully.

2 Likes

I'm at stage 4 of that now lol. It was only Civ4 Colonization and CoD4 MW that I was really booting Windows for, and they are both working fine on Garuda now, so the need for shared Win/Linux Steam storage is almost redundant now. Next re-install and Win is getting relegated to an HDD so Garuda gets the NVMe to itself.

1 Like

Checkmate, Bill. :wind_face: :window: :magic_wand: :magic_wand: :magic_wand: :penguin:

:100: :+1:

Personally I steer clear, as much as possible, of any Shared Data that involves NTFS, period.
Especially when Windows & Linux have write access. Just a general rule of thumb here.

Best of luck!

5 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.