Re: [PATCH] copy_file_range.2: Kernel v5.12 updates
From: Alejandro Colomar (man-pages) <hidden>
Date: 2021-02-27 12:21:35
Also in:
ceph-devel, linux-fsdevel, linux-man, linux-nfs, lkml
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)quoted
On 2/24/21 5:10 PM, Amir Goldstein wrote:quoted
On Wed, Feb 24, 2021 at 4:22 PM Luis Henriques [off-list ref] wrote:quoted
.TP +.B EOPNOTSUPPI'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.
quoted
quoted
quoted
.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.
*/:)
quoted
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.quoted
quoted
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
quoted
quoted
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/