Originally posted by AHOY
View Post
Yes this behaviour can change with software updates. So reuse is a lot harder. Yes being able to install a bottle/prefix and duplicate is a feature wine supports. relink copy a wine prefix I have done before xfs. This starts showing you how often programs do horrible things because files installed by something like dotnet you see programs modify global setting(as in files installed by the likes of dotnet' to suit their needs. Yes this global modification explains why if windows users installs a mixture of random applications they roll snake eyes from time to time. Yes the wine install 1 application per prefix is a diagnostic path to work out there is software conflict.
In a ideal software world you should be able to install all windows software in one wine prefix that don't require overrides. The reality is this does not work even under windows. Wineprefix is a work around to wine limitations and a windows limitation.
AHOY --reflink=always and --reflink=auto of the cp command are very useful when on a relink supporting file system to copy wineprefix/bottle with to keep sizes down to a point but as wine prefixes update you will notice they will also split from each other and you will have to run a deduplication pass to merge them back to each other.
Other thing to consider a runtime virtual file system does come with a overhead cost. relink route with a de-duplication tool is very light in overhead because you are working with a feature the file system supports.
Yes wine virtual file system for faking up case name insensitivity is very expensive and faking up something like reflinks is even more expensive as it would result in scanning more and more directories and having to do copy operations. AHOY there are just cases like case-folding and keeping wine prefix de-duplicated as possible you really do need for best performance file system support as native file systems can do this in synced structures without horrible overhead. The problem here is between the time you last scanned the file system and now how do you know if you are still current. File system global state is the problem to replicate as a layer on top. Global state as the file system itself is really simple to implement.
Do note even if wine did implement own overlay/reflinks in userspace you would still have the problem of needing de-duplication tool to merge prefixes back to only have 1 copy of a file when a file was updated in 2 or more prefixes to the same file by different applications.
Yes using btrfs or xfs reflink feature has manually been usable with wine for quite some time to keep prefix size down. Supporting auto reflinking when file system supports it will be beneficial. Even so after auto reflinking you still need a de-duplicate tool to scan over wine prefixes to find files that have been duplicated that need to be merged back for absolute ideal disc usage.
The annoying part about ZFS here is oracles ZFS does support reflink yet openzfs freebsd zfs and zfs for Linux don't. Yes ZFS on disc format has the structures to support reflinking.
EXT4 problem is it does not have the disc structures to effectively support reflinking a developer had a look at it again in 2014 and it was found you add reflink support to ext4 you have to add a wrapper layer to patch over the disc structures limitations that would result in lower performance. I am not talking small percentage drop here I am talking write operations being like 10-15% slower.
There is no ideal file system for wine under Linux. Case-folding limited file system support and reflink support limitations are both problems. Ideal file system for wine would support both.
Comment