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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
