Re: [PATCH 1/2] fuse: fix COPY_FILE_RANGE interface

[Bernd Schubert <bschubert@ddn.com>]

On 8/6/25 11:17, Luis Henriques wrote:
> On Tue, Aug 05 2025, Miklos Szeredi wrote:
> 
>> The FUSE protocol uses struct fuse_write_out to convey the return value of
>> copy_file_range, which is restricted to uint32_t.  But the COPY_FILE_RANGE
>> interface supports a 64-bit size copies.
>>
>> Currently the number of bytes copied is silently truncated to 32-bit, which
>> is unfortunate at best.
>>
>> Introduce a new op COPY_FILE_RANGE_64, which is identical, except the
>> number of bytes copied is returned in a 64-bit value.
>>
>> If the fuse server does not support COPY_FILE_RANGE_64, fall back to
>> COPY_FILE_RANGE and truncate the size to UINT_MAX - 4096.
> 
> I was wondering if it wouldn't make more sense to truncate the size to
> MAX_RW_COUNT instead.  My reasoning is that, if I understand the code
> correctly (which is probably a big 'if'!), the VFS will fallback to
> splice() if the file system does not implement copy_file_range.  And in
> this case splice() seems to limit the operation to MAX_RW_COUNT.

I personally don't like the hard coded value too much and would use

inarg.len = min_t(size_t, len, (UINT_MAX - 4096));

(btw, 0xfffff000 is UINT_MAX - 4095, isn't it?).

Though that is all nitpick. The worst part that could happen are
applications that do not handle partial file copy and then wouldn't
copy the entire file. For these it probably would be better to return
-ENOSYS.

LGTM, 

Reviewed-by: Bernd Schubert <bschubert@ddn.com>