vfs: Allow VOP_COPY_FILE_RANGE() to work across mount points.
Needs ReviewPublic
Actions

Authored by pjd on Feb 27 2023, 2:44 AM.

Details

Reviewers

allanjude
oshogbo

Summary

When executing the copy_file_range(2) syscall we check if both source
and destination files reside under the same mount point and only
then we would call file system spoecific VOP_COPY_FILE_RANGE() method.

For ZFS we want to have the ability to quickly clone files between
separate datasets within the same storage pool.

To make that possible, introduce the VFCF_CROSS_COPY_FILE_RANGE flag
that tells if the given file system type supports such use case.
If it does and the source and destination files both reside on the same
file system type call VOP_COPY_FILE_RANGE().

Note that the VOP_COPY_FILE_RANGE() can fail for many reasons (eg. ZFS
won't be able to clone a range not aligned to block boundaries), but the
generic copy may still be feasible and should be performed. To recognize
such situation the VOP_COPY_FILE_RANGE() implementation should return
the EXDEV error. If EXDEV is returned we will fall back to the generic copy.

Signed-off-by: Pawel Jakub Dawidek <pjd@FreeBSD.org>

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 50042
Build 46934: arc lint + arc unit

Event Timeline

pjd created this revision.Feb 27 2023, 2:44 AM

Herald added a subscriber: imp. · View Herald TranscriptFeb 27 2023, 2:44 AM

pjd requested review of this revision.Feb 27 2023, 2:44 AM

Harbormaster completed remote builds in B50042: Diff 117986.Feb 27 2023, 2:44 AM

My grep fails to find any existing custom routines, I'm guessing one for zfs will be showing up later. I think this also means there is no worry of any backwards-incompatible breakage.

I think the thing to do here instead of adding the flag is to blindly call VOP_COPY_FILE_RANGE, which can act however it sees fit. Should it be unable to handle cross-mount copies, it can fallback to vn_copy_file_range_cross_mount which will be just the existing vn_generic_copy_file_range.

The flag approach is definitely "traditional" here, but I just don't think it is warranted. If anything work should be done to decruft the layer where possible.

I would also like to point out you may have 2 nullfs mount points, both backed by the same zfs pool. In that case you would still preferably land in the zfs routine with full knowledge of what's up.

In D38803#883156, @mjg wrote:

My grep fails to find any existing custom routines, I'm guessing one for zfs will be showing up later. I think this also means there is no worry of any backwards-incompatible breakage.

It was initially implement for NFS to allow for server-local copies.

I think the thing to do here instead of adding the flag is to blindly call VOP_COPY_FILE_RANGE, which can act however it sees fit. Should it be unable to handle cross-mount copies, it can fallback to vn_copy_file_range_cross_mount which will be just the existing vn_generic_copy_file_range.

The flag approach is definitely "traditional" here, but I just don't think it is warranted. If anything work should be done to decruft the layer where possible.

I would also like to point out you may have 2 nullfs mount points, both backed by the same zfs pool. In that case you would still preferably land in the zfs routine with full knowledge of what's up.

Hmm, my expectation would be that the ZFS is the exception here and this way we avoid checking if both vnodes reside on the same file system in every file system specific method. On the other hand with very few file systems implementing this method adding this flag might be an overkill. I don't have a strong opinion on this.

BTW. I've prepared an alternative approach with the new flag:

https://reviews.freebsd.org/D38814

pjd mentioned this in D38814: Call VOP_COPY_FILE_RANGE() for the same file system type..Mar 1 2023, 11:32 AM