Re: reflink support and Samba running over XFS

[David Disseldorp <ddiss@samba.org>]

Hi Jeremy,

On Wed, 9 Nov 2022 10:47:41 -0800, Jeremy Allison via samba-technical wrote:

...
> >So the code change needed is to move the logic in vfs_btrfs.c
> >into vfs_default.c, and change the call in vfs_btrfs.c:btrfs_offload_write_send()
> >to SMB_VFS_NEXT_OFFLOAD_WRITE_SEND() to call the old fallback code
> >inside vfs_default.c (vfswrap_offload_write_send()).  
> 
> Although looking at the current Linux kernel I find inside:
> 
> ssize_t vfs_copy_file_range(struct file *file_in, loff_t pos_in,
> 			    struct file *file_out, loff_t pos_out,
> 			    size_t len, unsigned int flags)
> {
> 
> https://github.com/torvalds/linux/blob/0adc313c4f20639f7e235b8d6719d96a2024cf91/fs/read_write.c#L1506
> 
> 	/*
> 	 * Try cloning first, this is supported by more file systems, and
> 	 * more efficient if both clone and copy are supported (e.g. NFS).
> 	 */
> 	if (file_in->f_op->remap_file_range &&
> 	    file_inode(file_in)->i_sb == file_inode(file_out)->i_sb) {
> 		loff_t cloned;
> 
> 		cloned = file_in->f_op->remap_file_range(file_in, pos_in,
> 				file_out, pos_out,
> 				min_t(loff_t, MAX_RW_COUNT, len),
> 				REMAP_FILE_CAN_SHORTEN);
> 		if (cloned > 0) {
> 			ret = cloned;
> 
> and looking at the code supporting int ioctl(int dest_fd, FICLONERANGE, struct file_clone_range *arg);
> we have:
> 
> loff_t do_clone_file_range(struct file *file_in, loff_t pos_in,
> 			   struct file *file_out, loff_t pos_out,
> 			   loff_t len, unsigned int remap_flags)
> ...
> 	ret = file_in->f_op->remap_file_range(file_in, pos_in,
> 			file_out, pos_out, len, remap_flags);
> 
> 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().

copy_file_range() should be okay for FSCTL_SRV_COPYCHUNK, but I don't
think it's an option for FSCTL_DUP_EXTENTS_TO_FILE, as (IIRC) the latter
explicitly requires block cloning so can't fallback to regular copy.

Cheers, David