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

[phoronix]

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

Last month I wrote about the proposed reflink support for Wine that would provide significant space savings for those having multiple Windows games/applications on Linux installed where Wine and derivatives like Crossover and Steam Play (Proton) generally maintain a separate "prefix" per software installation. Fortunately, that reflink support continues to be worked on for Wine where it can lead to savings up to several hundred megabytes per Wine prefix...

https://www.phoronix.com/scan.php?page=news_item&px=Wine-Reflink-Revised

[Developer12]

If ext4 doesn't have support, how much use is this actually going to bring? Afaik, damn near everyone (debian/ubuntu most notably) is still on ext4 unless you're a fedora/arch user and like to live dangerously (btrfs).

[Etherman]

Developer12 Steam deck?

[V1tol]

We already discussed that in previous news about reflink, but I still don't understand why you can't use symlinks for that. Writing into files does not look like a problem to me - most of the space is occupied by different system DLLs where you cant and shouldnt write. Even if someone is trying to open kernel32.dll for writing - you could just have a slow workaround in Wine code detecting this, making an explicit copy and opening that copied file for writing. Different installers are just overwriting files, not opening them for writing. And other stuff like registry files etc where you write a lot should not be symlinked at all.

[S.Pam]

We already discussed that in previous news about reflink, but I still don't understand why you can't use symlinks for that. Writing into files does not look like a problem to me - most of the space is occupied by different system DLLs where you cant and shouldnt write. Even if someone is trying to open kernel32.dll for writing - you could just have a slow workaround in Wine code detecting this, making an explicit copy and opening that copied file for writing. Different installers are just overwriting files, not opening them for writing. And other stuff like registry files etc where you write a lot should not be symlinked at all.

I guess it is easier to update in-place and not have to deal with conflicting versions and other differences.

[S.Pam]

If ext4 doesn't have support, how much use is this actually going to bring? Afaik, damn near everyone (debian/ubuntu most notably) is still on ext4 unless you're a fedora/arch user and like to live dangerously (btrfs).

Several distros and system use Btrfs these days. It is considered mature and stable. The world is full of anectotal evidence to the contrary for any filesystem, but that in itself doesn't make them risky filesystems.

[blacknova]

If ext4 doesn't have support, how much use is this actually going to bring? Afaik, damn near everyone (debian/ubuntu most notably) is still on ext4 unless you're a fedora/arch user and like to live dangerously (btrfs).

Any FS or OS could be unstable on faulty hardware or under specific workloads. I've seen Windows crashing randomly while Linux were stable with certain RAM settings, or BTRFS panicing on old SATA SSD while EXT4 or NTFS were rock stable.

[Britoid]

Several distros and system use Btrfs these days. It is considered mature and stable. The world is full of anectotal evidence to the contrary for any filesystem, but that in itself doesn't make them risky filesystems.

A lot of workstations also use XFS, which is considered extremely stable.

[skeevy420]

If ext4 doesn't have support, how much use is this actually going to bring? Afaik, damn near everyone (debian/ubuntu most notably) is still on ext4 unless you're a fedora/arch user and like to live dangerously (btrfs).

XFS, Bcachefs, and BTRFS support it.

OpenZFS technically has it (Solaris ZFS feature) but there's no Linux interface to it...though we could just create a Wine dataset with deduplication enabled for the same effect...

[oiaohm]

Even if someone is trying to open kernel32.dll for writing - you could just have a slow workaround in Wine code detecting this, making an explicit copy and opening that copied file for writing.

Problem here is that would not work. Because you would have to be running a check on every open or check on every fail to write error. I do agree that some of the dll could be symlinked but the ones application installers over write could not be. The reality is the symlinked files would have to be attempt to open for writing fail. There is a party that has fully looked at doing symlink and hardlink deduplication that is the developers behind ostree. Yes the idea of making a copy when this happens also turns out to be horrible due to the on going overhead.

Please beware a reflink if only 1block in a file has changed that all that being written to disc + some meta data so this is fast. There is also no difference in modify a reflinked file first a normal by self file in processing time. So reflinking registry files is no problem.

Wine would be able to symlink the registery in some case if the multi user support code ever gets implemented. Yes the current wine default that you are always a admin privilege user means you are meant to have write access to all registry but when you are normal user there are particular registries you are not meant to have write access to.

Symlinking the dll applications are not meant to change ever would only be about 1/4 of the savings still disc space saving and prefix initialisation time saving.

There is another downside to symlink vs reflink. If wine is uninstalled from system install in a reflink case the contents of the wine prefix will still be intact in the home directory with the symlink this is not the case either. This difference is sometimes important when attempting to work out different errors. Yes it is possible to work out wine versions at times that have been used on wine prefix from the dll and the registry.

Yes implementing the symlinked path is a lot more complex as you have to make a list of what will be fine as read only. Read/write with the symlink/hardlink path is just not a option. ostree developers did try there is a lot more overhead to the trapping than one would think and then you have the errors where the trapping fails for some reason.

Please note I am not saying that the symlinked or hardlinked path should not be looked into. Because really it should due to broader file system support. Remember even if you have a file system that support reflink there is a reflink limitation that if wine is install on one partition and you how directory is on another reflink does not work.

I can understand doing reflink first as well. Because if you cannot get reflink to work that does not have the limitations of symlinked/hardlinks you are not going to get symlinked/hardlinked to work.