Messages in this thread | | | Subject | Re: [PATCH] copy_file_range.2: Kernel v5.12 updates | From | "Alejandro Colomar (man-pages)" <> | Date | Sat, 27 Feb 2021 13:20:31 +0100 |
| |
Hi Amir,
On 2/27/21 6:41 AM, Amir Goldstein wrote: > On Sat, Feb 27, 2021 at 12:19 AM Alejandro Colomar (man-pages) >> On 2/24/21 5:10 PM, Amir Goldstein wrote: >>> On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques <lhenriques@suse.de> wrote: >>>> .TP >>>> +.B EOPNOTSUPP >> >> I'll add the kernel version here: >> >> .BR EOPNOTSUPP " (since Linux 5.12)" > > Error could be returned prior to 5.3 and would be probably returned > by future stable kernels 5.3..5.12 too
OK, I think I'll state <5.3 and >=5.12 for the moment, and if Greg adds that to stable 5.3..5.11 kernels, please update me.
>>>> .B EXDEV >>>> The files referred to by >>>> .IR fd_in " and " fd_out >>>> -are not on the same mounted filesystem (pre Linux 5.3). >>>> +are not on the same mounted filesystem (pre Linux 5.3 and post Linux 5.12). >> >> I'm not sure that 'mounted' adds any value here. Would you remove the >> word here? > > See rename(2). 'mounted' in this context is explained there. > HOWEVER, it does not fit here. > copy_file_range() IS allowed between two mounts of the same filesystem instance.
Also allowed for <5.3 ?
> > To make things more complicated, it appears that cross mount clone is not > allowed via FICLONE/FICLONERANGE ioctl, so ioctl_ficlonerange(2) man page > also uses the 'mounted filesystem' terminology for EXDEV > > As things stand now, because of the fallback to clone logic, > copy_file_range() provides a way for users to clone across different mounts > of the same filesystem instance, which they cannot do with the FICLONE ioctl. > > Fun :) > > BTW, I don't know if preventing cross mount clone was done intentionally, > but as I wrote in a comment in the code once: > > /* > * FICLONE/FICLONERANGE ioctls enforce that src and dest files are on > * the same mount. Practically, they only need to be on the same file > * system. > */
:)
> >> >> It reads as if two separate devices with the same filesystem type would >> still give this error. >> >> Per the LWN.net article Amir shared, this is permitted ("When called >> from user space, copy_file_range() will only try to copy a file across >> filesystems if the two are of the same type"). >> >> This behavior was slightly different before 5.3 AFAICR (was it?) ("until >> then, copy_file_range() refused to copy between files that were not >> located on the same filesystem."). If that's the case, I'd specify the >> difference, or more probably split the error into two, one before 5.3, >> and one since 5.12. >> > > True. > >>> >>> I think you need to drop the (Linux range) altogether. >> >> I'll keep the range. Users of 5.3..5.11 might be surprised if the >> filesystems are different and they don't get an error, I think. >> >> I reworded it to follow other pages conventions: >> >> .BR EXDEV " (before Linux 5.3; or since Linux 5.12)" >> >> which renders as: >> >> EXDEV (before Linux 5.3; or since Linux 5.12) >> The files referred to by fd_in and fd_out are not on >> the same mounted filesystem. >> > > drop 'mounted'
Yes
> >> >>> What's missing here is the NFS cross server copy use case. >>> Maybe: >>> >>> ...are not on the same mounted filesystem and the source and target filesystems >>> do not support cross-filesystem copy. >> >> Yes. >> >> Again, this wasn't true before 5.3, right? >> > > Right. > Actually, v5.3 provides the vfs capabilities for filesystems to support > cross fs copy. I am not sure if NFS already implements cross fs copy in > v5.3 and not sure about cifs. Need to get input from nfs/cis developers > or dig in the release notes for server-side copy.
Okay > Thanks to LWN :)
:)
Thanks,
Alex
-- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
| |