Re: [nfsv4] Inter server-side copy performance

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Apr 18, 2017 at 01:28:39PM -0400, Olga Kornievskaia wrote:
> Given how the code is written now it looks like it's not possible to
> save up commits....
> 
> Here's what I can see happening:
> 
> nfs42_proc_clone() as well as nfs42_proc_copy() will call
> nfs_sync_inode(dst) "to make sure server(s) have the latest data"
> prior to initiating the clone/copy. So even if we just queue up (not
> send) the commit after the executing nfs42_proc_copy, then next call
> into vfs_copy_file_range() will send out that queued up commit.
> 
> Is it ok to relax the requirement that requirement, I'm not sure...

Well, if the typical case of copy_file_range is just opening a file,
doing a single big copy_file_range(), then closing the file, then this
doesn't matter.

The linux server is currently limiting COPY to 4MB at a time, which will
make the commits more annoying.

Even there the typical case will probably still be an open, followed by
a series of non-overlapping copies, then close, and that shouldn't
require the commits.

--b.