Ralph Böhme slow at samba.org
Sun May 7 11:30:48 UTC 2017

Hi David,

nice work! Some nitpicks below...

On Thu, May 04, 2017 at 05:30:35PM +0200, David Disseldorp via samba-technical wrote:
> Please find attached a patchset from Aurélien and myself, which adds
> support for FSCTL_DUPLICATE_EXTENTS_TO_FILE - a new reflink/clone FSCTL
> supported on Windows Server 2016 shares backed by ReFS.
> A couple of things that I'm still a little unsure about:
> - It might be cleaner to move the locking calls out of the copy-chunk
>   VFS function (drop VFS_COPY_CHUNK_FL_IGNORE_LOCKS), and move them
>   into fsctl_srv_copychunk_loop(). Thoughts?

Yeah, probably makes sense, but I'd have to take a closer look. As I'm going to
do some larger changes here in the near future for offload read/write as, I can
move the locking stuff around as part of that.

> - The server behaviour for success on truncated clone (where the
>   dest file's allocation size is less than the size of the clone) seems
>   prone to races, especially given that the operation ignores locks.
>   + See test_ioctl_dup_extents_len_beyond_dest(). Dochelp are aware of
>     this inconsistency.
>   + There's not much we can do here, as we need to match Windows Server
>     2016 + ReFS behaviour.


[PATCH 03/10] vfs: add parameter to copy chunk VFS function to handle dup_extents

TODO: please move "[ddiss at samba.org: split VFS API change from  ioctl code]" to subject body

otherwise rb: me.

[PATCH 4/10] smbd/smb2_ioctl: add support for FSCTL_DUPLICATE_EXTENTS_TO_FILE

- initialize all pointer vars to NULL
- use DEBUG helper macros DBG_ERR, DBG_INFO, ...
- fsctl_dup_extents_send/recv() must create a tevent_req and return that
  and not just return the SMB_VFS_COPY_CHUNK_SEND subreq
- empty line between var declaration and subsequent first statement

Everything else: reviewed-by: me.

Fwiw, I tested copy behaviour of a Windows 10 client against Windows 2016
sharing a refs filesystem, as discussed last week. What I see is:

- server returns FILE_SUPPORTS_BLOCK_REFCOUNTING in volume attributes

- copying a 100 MB file with c-c -> c-v in the same share

- client issues offload read ioctl

- server returns invalid device request

- client falls back to copy-chunk

I don't see clone-range on the wire, trace attached. Am I missing something?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy-file.pcapng.gz
Type: application/gzip
Size: 24014 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170507/5f6a0d26/copy-file.pcapng.gz>

More information about the samba-technical mailing list