Re: [nfsv4] Inter server-side copy performance

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

On Fri, Apr 14, 2017 at 05:22:13PM -0400, Olga Kornievskaia wrote:
> On Fri, Apr 14, 2017 at 4:09 PM, Mora, Jorge <Jorge.Mora@netapp.com> wrote:
> > On 4/13/17, 11:45 AM, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> >> Are you timing just the copy_file_range() call, or do you include a
> >> following sync?
> >
> > I am timing right before calling copy_file_range() up to doing an fsync() and close() of the destination file.
> > For the traditional copy is the same, I am timing right before the first read on the source file up to the
> > fsync() and close() of the destination file.
> 
> Why should do we need a sync after copy_file_range(). kernel
> copy_file_range() will send the commits for any unstable copies it
> received.

Why does it do that?  As far as I can tell it's not required by
documentation for copy_file_range() or COPY.  COPY has a write verifier
and a stable_how argument in the reply.  Skipping the commits would
allow better performance in case a copy requires multiple COPY calls.

But, in any case, if copy_file_range() already committed then it
probably doesn't make a significant difference to the timing whether you
include a following sync and/or close.

--b.