Wine Reflink Support Continues To Be Worked On For Significant Space Savings

[avem]

I've got a few wine bottles/prefixes and I've solved the issue manually by just symlinking the C:\Windows directory across all of them. It's relatively safe because Wine doesn't store any prefix-specific data in it except MSI installers but then they are normally uniquely named, so conflicts cannot occur. It's worked for me perfectly for for over a decade now.

[Etherman]

Iirc you can mount XFS with 32bit inodes now which should resolve the issue.

Well problem solved then 👍 for those who know about it

[Etherman]

I've been considering a switch to btrfs for some time. Are there any noticeable performance differences between btrfs and ext4?

No, no noticable performance differences unless doing lots of writes to one and same big file, such as virtual harddrive images for virtual machines or big databases, especially on spinning rust. Files that get writen to much gets very fragmented unless setting a special file attribute, chattr +C, but then you loose checksumming on that file.

[leipero]

yes, you are missing something here. you suggested overcomplicated algorithm under disguise of simplification while reflink solution is trivial "use reflink instead of copy if available"

And I'm still missing it to be fair, can't see how a simple "if" statement or override is overcomplication while reflinks are not, I just can't see it if someone doesn't explain it to me.

On the contrary. Reflinks are easy, need no complicated rules to manage and are transparent to any application.

cp --reflink /foo /bar

Ok, but what is the difference? You have two solutions:
1. Copy reflink, potentially save some minor space, be limited by a file system if you want to use it.
2. Use symlink, potentially use a bit more space, not limited by FS.
Either way, override managment is there to begin with in WINE, so I really struggle to see the need for reflink at all. You want to edit something or override it? No problem, use copy of the file in the local prefix = problem solved.

[S.Pam]

And I'm still missing it to be fair, can't see how a simple "if" statement or override is overcomplication while reflinks are not, I just can't see it if someone doesn't explain it to me.



Ok, but what is the difference? You have two solutions:
1. Copy reflink, potentially save some minor space, be limited by a file system if you want to use it.
2. Use symlink, potentially use a bit more space, not limited by FS.
Either way, override managment is there to begin with in WINE, so I really struggle to see the need for reflink at all. You want to edit something or override it? No problem, use copy of the file in the local prefix = problem solved.

I guess you have to simply try it yourself. On my system, I have an alias for cp="cp --reflink=auto" which means it will reflink on all filesystems that does it.

How does a symlink save more space while avoiding the risk of mixing up different versions of dll's etc?

[S.Pam]

There is one problem with btrfs reflinks: if you have two subvolumes independently mounted you won't be able to reflink between them. This is especially annoying when you have snapper snapshots and you try to reflink from a snapshot onto your rw subvolume. Instead, if you mount your root btrfs volume containing all of your subvolumes inside, from there you can reflink between subvolumes. This looks like an easy thing to fix to me, I'm wondering why nobody still patched it up

This is AFAIK a limitation of Linux VFS layer and not a limitation in Btrfs code. But I agree, it should be fixed, but the people needing to fix it are those developing VFS and not the Btrfs devs.

[S.Pam]

No, no noticable performance differences unless doing lots of writes to one and same big file, such as virtual harddrive images for virtual machines or big databases, especially on spinning rust. Files that get writen to much gets very fragmented unless setting a special file attribute, chattr +C, but then you loose checksumming on that file.

There is also "btrfs filesystem defrag" that you can run now and then if you do notice a performance impact due to fragmentation. It can be run while your VM is running. There is also mount -o autodefrag which does it automatically, though the impact on HDDs can be a little irratic, depending on your read/write patterns.

[leipero]

I guess you have to simply try it yourself. On my system, I have an alias for cp="cp --reflink=auto" which means it will reflink on all filesystems that does it.

How does a symlink save more space while avoiding the risk of mixing up different versions of dll's etc?

Well, I can't use reflink anyway on EXT4. I don't really understand what you mean by avoiding the risk of mixing up different versions of dll's? If you use dll override in WINE, you are already "mixing versions" because built in WINE solution isn't really any version to begin with, and of you mean for prefixes, well, every prefix uses different location, so as far as I can see, it's a non-issue because "base" is always the same = WINE versions.
If you are talking about multi WINE versioning, that's another thing, but still, I can't see the problem there either, plus, that should be a task of prefix manager such as Lutris or POL etc.

[S.Pam]

... every prefix uses different location, so as far as I can see, it's a non-issue.

This is the point. Instead of having to have a copy of mostly the same DLL's in each prefix, you reflink them. If you had used symlinks and you need to change or add some DLL due to the game or whatnot, then it will overwrite the files shared by other prefixes.

[NobodyXu]

Well, I can't use reflink anyway on EXT4. I don't really understand what you mean by avoiding the risk of mixing up different versions of dll's? If you use dll override in WINE, you are already "mixing versions" because built in WINE solution isn't really any version to begin with, and of you mean for prefixes, well, every prefix uses different location, so as far as I can see, it's a non-issue because "base" is always the same = WINE versions.
If you are talking about multi WINE versioning, that's another thing, but still, I can't see the problem there either, plus, that should be a task of prefix manager such as Lutris or POL etc.

Because most of the file WINE is running didn’t have symlink support in mind.

They assumes that the open give them the file, not a symlink.
After opening the file, they would just update it without replacing that symlink with an actual file.

If you would like to add symlink handling support to prefix, then you would have to patch the interception of syscall/library call in WINE, to detect if the app is trying to open the prefix to be writeable, and update it according.
It’s likely it will introduce more bugs into WINE…

One easy alternative way is to use overlayfs.
It can be run over any filesystem to give it “copy on write” semantics, though generally it copies the whole file on write.
With some more complex runtime setup (need to mount overlayfs for every prefix for each application, requires sudo unless using fuse overlayfs, which have worse performance than in-kernel implementation), you can get it to act like reflink.

The downside, is if you are using in-kernel implementation of overlayfs, then kernel version >= 3.18 is needed and WINE needs to run as root to mount the overlayfs.

If you are using the fuse implementation (userpspace implementation), then you won’t need kernel version >= 3.18 or WINE to run as root, but fuse implementation is going to be slower on opening the file, though reading/writing the file is on par with native filesystem.