Re: reflink support and Samba running over XFS

[David Disseldorp <ddiss@samba.org>]

On Thu, 10 Nov 2022 03:42:28 -0800, Christoph Hellwig wrote:

> On Wed, Nov 09, 2022 at 11:30:55PM +0100, David Disseldorp via samba-technical wrote:
> > I think it's doable too :-). As indicated in my other mail, I think
> > FICLONERANGE will need to be used for FSCTL_DUP_EXTENTS_TO_FILE instead
> > of copy_file_range().
> > I'm not sure how to best handle FILE_SUPPORTS_BLOCK_REFCOUNTING -
> > ideally we'd set it for Btrfs and XFS(reflink=1) backed shares only.
> > Another option might be to advertise FILE_SUPPORTS_BLOCK_REFCOUNTING and
> > then propagate errors up to the client if FICLONERANGE fails for
> > FSCTL_DUP_EXTENTS_TO_FILE. Client copy fallback would work, but the
> > extra request overhead would be ugly.  
> 
> We could probably add a bit to struct statx if that is helpful for
> samba.

I think that'd be helpful for the above example.

The corresponding MS-FSA spec states:
  2.1.5.9.4 FSCTL_DUPLICATE_EXTENTS_TO_FILE
  ...
  The purpose of this operation is to make it look like a copy of a region from the source stream to the
  target stream has occurred when in reality no data is actually copied. This operation modifies the
  target stream's extent list such that, the same clusters are pointed to by both the source and target
  streams' extent lists for the region being copied.

So it would appear that SMB clients can expect metadata I/O only.

There's one other SMB caveat which should be considered with any statx
changes, from MS-FSCC:

  2.3.9 FSCTL_DUPLICATE_EXTENTS_TO_FILE_EX Request
  ...
  When the DUPLICATE_EXTENTS_DATA_EX_SOURCE_ATOMIC
  flag isn’t set, the behavior is identical to FSCTL_DUPLICATE_EXTENTS_TO_FILE. When the flag is set,
  duplication is atomic from the source's point of view. It means duplication fully succeeds or fails
  without side effect (when only part of source file region is duplicated).

Cheers, David