Re: Same mountpoint restriction in FICLONE ioctls

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+CC XFS,NFS,CIFS

On Sun, Apr 12, 2020 at 1:06 PM Keno Fischer <keno@xxxxxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> I was curious about the reasoning behind the
> same-mountpoint restriction in the FICLONE
> ioctl. I saw that in commit
>
> [913b86e92] vfs: allow vfs_clone_file_range() across mount points
>
> this check was moved from the vfs layer into
> the ioctl itself, so it appears to be a policy restriction
> rather than a technical limitation. I understand why
> hardlinks are disallowed across mount point boundaries,
> but it seems like that rationale would not apply to clones,
> since modifying the clone would not affect the original
> file. Is there some other reason that the ioctl enforces
> this restriction?
>

I don't know. I suppose that when FICLONE was introduced
there wasn't any use case for cross mount clone.

Note that copy_file_range() also had this restriction, which was
recently lifted, because NFSv4 and CIFS needed this functionality.

As far as I can tell, CIFS and NFSv4 can also support cross mount
clone, but nobody stepped up to request or implement that.

The question is: do you *really* need cross mount clone?
Can you use copy_file_range() instead?
It attempts to do remap_file_range() (clone) before falling back to
kernel copy_file_range().

> Removing this restrictions would have some performance
> advantages for us, but I figured there must be a good reason
> why it's there that I just don't know about, so I figured I'd ask.
>

You did not specify your use case.
Across which filesystems mounts are you trying to clone?

Thanks,
Amir.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux