So how would this actually work? When I create a new prefix, where does it get the original files to ref-link? ~/.wine is the default Wine prefix, but not necessarily one created with the same Wine version used to create the new prefix... I just don't understand how this could work without a Wine manager that knows which profile are using same Wine version and which are not. Will they be ref-linked from the system-installed package? I guess that should be acceptable for those that only have 1 version installed at a time.
Announcement
Collapse
No announcement yet.
Proposed Reflink Support Would Provide Big Space Savings For Wine
Collapse
X
-
Originally posted by geearf View PostSo how would this actually work? When I create a new prefix, where does it get the original files to ref-link? ~/.wine is the default Wine prefix, but not necessarily one created with the same Wine version used to create the new prefix... I just don't understand how this could work without a Wine manager that knows which profile are using same Wine version and which are not. Will they be ref-linked from the system-installed package? I guess that should be acceptable for those that only have 1 version installed at a time.
The vast majority of these files are byte-for-byte identical to Wine's central DLL copies.
Of course if your location where wine is system wide installed is on a different partition to your home directory this relink solution in it current form is not going to work.
The explosion in wine prefix size is directly linked to the move from wine pe/elf to pe Yes in the pe/elf day the dll files in the wine prefix were a lot smaller due to being fakes with as small as code as possible just to redirect to the pe/elf binary bad new copy protection stuff hated finding elf headers and dll stacking. What use to be under 5 meg per wine prefix elf/pe with fake dlls has exploded to 150-300 megs in the PE dll time frame yes reflinking brings this back to 1 meg. The old fakedlls were not exactly the most disc effective option.
I see this as first step. I do wonder if support of a wine user to reflink against on a users home directory when that home directory is a different partition may be a good thing but I see this as a future problem. Please note you really don't want to be reflinking masters from something in the users home directory that could have been damaged by a install of a program when attempting to diagnose issues. With the way reflink works you get a error wine a reflink cannot be done so it is possible to have multi master copies with 1 master copy per partition and systematically attempt reflink after reflink until one works and if non works drop back to copy.
You can instantly clone files on many copy-on-write (CoW) file systems. But how do you do that in different operating and file systems?
Please note this reflink support long term is not only need to solve the wineprefix size explosion caused by going PE. It is also need to support applications expecting refs2 and to use "DUPLICATE_EXTENTS_TO_FILE" feature under windows. Yes you need applications to know if a file has managed to be de-duplicated or not. Yes some applications will alter their operations when they find that X location will not de-duplicate straight away.
So reflink support by some means over time will come a more required feature.
Comment
-
Originally posted by sandy8925
I just mounted Windows NTFS/FAT partition under Linux and used it that way. Surprisingly this worked well with Witcher 3 on Windows.
1) Bad performance if you use the NTFS-3g fuse driver;
2) Unstability, data corruption if you use the upcomming "NTFS3" driver (from my experience, I hope it gets better);
3) Symlinks made with NTFS-3g and NTFS3 are not compatible with each other, and not compatible with Windows. Makes a mess! ;
4) Steam/Proton compatdata (wine prefixes) doesn't seem to work correctly on NTFS.
Comment
-
Originally posted by NobodyXu View Post
What they say is that zfs is fast enough that the bottleneck is the disk itself, and adding this syscall merely helps with deduplicate blocks.
They are not saying that it is undoable, since CoW filesystem, by its nature, split files into blocks so that on write, only the blocks that are updated and the meta blocks need to be added to the disk as new blocks.
They could easily support reflink by simply copy over references to the old blocks.
BTRFS also uses the same way since it is also a CoW filesystem, and if BTRFS can do it, there’s nothing by design that ZFS cannot do.
And no, what they say is exactly what they say — that zfs does not (yet) support reflinks, not that zfs is "fast enough" or anything else.
Comment
-
Another good option for shared storage is UDF. It's meant for DVD originally, but it works well for all kinds of media, including USB, HDD and SSD. It supports links and UNIX permissions among other stuff. Technically even something like (frozen) snapshots should are possible. Full RW support is available on almost any notable OS. Probably the most widely supported FS by far. It's surprising how little it's used.
If you're really hardcore and need to access a LUKS/LVM/bcache/btrfs volume or something similarly convoluted on Windows a small Linux VM that mounts and exports that over NFS (or SMB) also works well. Performance with VBox and qemu sucks badly though, but VMware easily pushes hundreds of MB/s over the virtual network.
Comment
-
Originally posted by NobodyXu View PostWhat they say is that zfs is fast enough that the bottleneck is the disk itself, and adding this syscall merely helps with deduplicate blocks.
Originally posted by NobodyXu View PostThey are not saying that it is undoable, since CoW filesystem, by its nature, split files into blocks so that on write, only the blocks that are updated and the meta blocks need to be added to the disk as new blocks.
Originally posted by NobodyXu View Postthere’s nothing by design that ZFS cannot do.Last edited by pal666; 27 July 2021, 10:13 AM.
Comment
-
Originally posted by landeel View Post4) Steam/Proton compatdata (wine prefixes) doesn't seem to work correctly on NTFS.
That one is answered in the wine FAQ. NTFS-3g is missing a feature lot steam hosted applications/games expect to work. This does not matter if it steam proton or the game installed in wine directly with some of these feature either. Yes using ext4 as a loop back file on a NTFS to run wine games can stupidly work out better than running straight on ntfs-3g.
Comment
-
Originally posted by binarybanana View PostAnother good option for shared storage is UDF. It's meant for DVD originally, but it works well for all kinds of media, including USB, HDD and SSD. It supports links and UNIX permissions among other stuff. Technically even something like (frozen) snapshots should are possible. Full RW support is available on almost any notable OS. Probably the most widely supported FS by far. It's surprising how little it's used.
Not really there is a nice little catch here. Yes Linux can read 2.50 and 2.60 UDF but cannot write it. Windows can auto update UDF 2.0x to 2.50/2.60. This leads to the fun you were able to read write 2.0x in Linux you boot into windows copy a file and now its read only when you return to Linux. This is another case driver support is problem. Please note mac os also says stuff you if windows upgraded UDF to 2.60
Using a file server like SMB/NFS is way less of odd ball stuff happening when sharing files between OS..
Comment
-
Originally posted by intelfx View PostAnd no, what they say is exactly what they say — that zfs does not (yet) support reflinks, not that zfs is "fast enough" or anything else.
Comment
Comment