[PATCH 5/5] vfs_default: add copy_file_range support for copy chunk

[David Disseldorp]

On Mon, 13 Feb 2017 16:36:47 +0100, Björn JACKE wrote:

> On 2017-02-08 at 11:57 +0100 David Disseldorp sent off:
> > IMO it's still worth splitting for the reasons mentioned earlier:
> >   + this would avoid the 8M I/O buffer allocation in the fast-path.  
> 
> have a look at the latest patch, this allocation isn't done in the fast path any
> more.
> 
> >   + mid-function #ifdef pollution would be avoided.  
> 
> the latests patch is visibly and logically separated from the manual copy code
> and the "fallback" path. I would like to keep it as it is in this patch here as
> I think the separation is clean and the overhead is minimized.
> 
> >   + I/O sizes could be tuned independently of the read/write loop.  
> 
> the I/O size is not an issue for the fast path as this is a one-shot call
> there. There is no need for a maximum read/write chunk with copy_file_range.

1684         SMB_VFS_STRICT_UNLOCK(src_fsp->conn, src_fsp, &lck);
1685         SMB_VFS_STRICT_UNLOCK(dest_fsp->conn, dest_fsp, &lck);

The src and dest lock_structs should be separate variables here.

I suppose not having the while loop around the copy_file_range calls
should be okay for now, as the copy-chunk caller currently only allows
for 1M chunk I/Os from the client.
The in kernel minimum appears to be 4M (for NFS), so short I/Os
shouldn't be encountered.

I still remain very much in favour of splitting this functionality out
into a separate function. It doesn't have to be a separate hook wrapper.

Cheers, David