[PATCH v3 0/5] Implement reflink support

[Alex Xu (Hello71)]

Excerpts from Alexandre Julliard's message of February 6, 2022 9:51 am:
> "Alex Xu (Hello71)" <alex_y_xu at yahoo.ca> writes:
>> Full reflink functionality with arbitrary offsets and overwrite is 
>> non-trivial to implement in the filesystem. However, we really only need 
>> the limited functionality of a whole-file reflink. This could be 
>> simulated using a hard or symbolic link which gets broken by Wine when 
>> any write occurs. However, as with reparse points, this requires 
>> modifying every file access that Wine makes, which would be a 
>> significant undertaking.
> 
> I'm not convinced that it would be that hard, and if it can work it
> would clearly be a better approach. Prefix size is a real problem, but I
> don't think reflinks are the answer.
> 
> -- 
> Alexandre Julliard
> julliard at winehq.org
> 

I disfavor the "magic symlink" approach for three reasons:

1. Implementing copy_file_range for CopyFile improves performance not 
only for wineboot, but also for every program using CopyFile. It allows 
reflink but also remote-side copy for cifs on Linux. I doubt anybody has 
Wine prefix on cifs, but maybe some people put files or programs on a 
network drive.

2. Who will review the resulting patch? This submission is now the third 
revision of this patchset with no non-trivial review. While we may 
disagree on whether "magic symlink" will be 2x or 10x the current 
patchset, it will certainly be larger. In particular, the setupapi part, 
which is the most complex part of this patchset, will certainly be 
larger and even more complex; passing file names down to write_fake_dll 
is harder than passing file handles, not easier.

3. Who will fix the resulting breakage in winetricks, protontricks, and 
who knows what other programs? As far as I can tell, any option for 
representing the magic link on the Unix side will result in issues. 
Either it uses symlinks, and "cp override_mydll.dll .../mydll.dll" will 
be broken, or it doesn't create the Unix side files, so ls will be 
broken, or it uses empty files, which is possibly the least worst 
solution but will break either "cp mydll.dll mydll2.dll" or "cp -a 
$WINEPREFIX $WINEPREFIX.bak", depending on the Wine implementation.

That being said, I am perfectly happy for someone else to write this 
"magic symlink" implementation. I agree that the full reflink 
functionality is not required, and it would be more beneficial to users 
to reduce prefix sizes on ext4. Even though most other Linux filesystems 
support reflink (even XFS, which is not CoW), ext4 is still the most 
popular option. However, I will not implement this, as I have already 
spent significant time working on this with no serious response from 
Wine project, only some side comments. "can it work on mac" is a fine 
question to ask, but is not actionable.

Alex.