reflink support and Samba running over XFS

Jeremy Allison jra at
Wed Nov 9 19:24:26 UTC 2022

On Wed, Nov 09, 2022 at 10:47:41AM -0800, Jeremy Allison wrote:
>So it *looks* like the copy_file_range() syscall will internally
>call the equivalent of FICLONERANGE if the underlying file
>system supports it.
>So maybe the right fix is to remove the FICLONERANGE specific
>code from our vfs_btrfs.c and just always use copy_file_range().
>Any comments from other Samba Team members ?

So right now Steve what is preventing FSCTL_DUP_EXTENTS_TO_FILE
from working against anything other then btrfs on Samba is the
following code:


180         if ((dst_fsp->conn->fs_capabilities
181                                 & FILE_SUPPORTS_BLOCK_REFCOUNTING) == 0) {
182                 DBG_INFO("FS does not advertise block refcounting support\n");
183                 tevent_req_nterror(req, NT_STATUS_INVALID_DEVICE_REQUEST);
184                 return tevent_req_post(req, ev);
185         }

because currently only the vfs_btrfs module reports FILE_SUPPORTS_BLOCK_REFCOUNTING,
not vfs_default.

and also in:


2194         case FSCTL_DUP_EXTENTS_TO_FILE:
2195                 DBG_DEBUG("COW clones not supported by vfs_default\n");
2196                 tevent_req_nterror(req, NT_STATUS_INVALID_PARAMETER);
2197                 return tevent_req_post(req, ev);

but looking at vfs_btrfs it looks like that code should
probably also be in vfswrap_offload_read_send() as well
and the error code should be NT_STATUS_INVALID_DEVICE_REQUEST.

We also need to duplicate the logic in vfs_btrfs for
handling FSCTL_DUP_EXTENTS_TO_FILE into VFS default,
gated on support for the copy_file_range() system
in the fs_capabilities return from vfs_default).

I think this is doable with some work...

More information about the samba-technical mailing list