[PATCH 5/5] vfs_default: add copy_file_range support for copy chunk
ddiss at samba.org
Tue Feb 14 01:00:24 UTC 2017
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
> > + 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.
More information about the samba-technical