Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 14 Apr 2021 13:28:25 -0400
From:   "bfields@fieldses.org" <bfields@fieldses.org>
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "trondmy@kernel.org" <trondmy@kernel.org>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "kolga@netapp.com" <kolga@netapp.com>,
        "bfields@redhat.com" <bfields@redhat.com>
Subject: Re: [PATCH 2/2] NFSv42: Don't force attribute revalidation of the
 copy offload source
Message-ID: <20210414172825.GE16800@fieldses.org>
References: <20210414143138.15192-1-trondmy@kernel.org>
 <20210414143138.15192-2-trondmy@kernel.org>
 <20210414144033.GC16800@fieldses.org>
 <20210414170519.GD16800@fieldses.org>
 <608b1babd125f72517a5116c4ed1e39e8104ae52.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <608b1babd125f72517a5116c4ed1e39e8104ae52.camel@hammerspace.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk

On Wed, Apr 14, 2021 at 05:23:53PM +0000, Trond Myklebust wrote:
> On Wed, 2021-04-14 at 13:05 -0400, J. Bruce Fields wrote:
> > On Wed, Apr 14, 2021 at 10:40:33AM -0400, bfields wrote:
> > > Thanks!  Testing....
> > 
> > ... and, test results back with these two patches applied, looks
> > good!
> 
> So, just out of curiosity. With which backing filesystem were you
> testing? If it was XFS, then note that you may have been testing the
> CLONE functionality instead of copy offload. As you saw, I added the
> same fix for both clone and copy offload because they have the same
> requirements for how the page and attribute caches are handled, so the
> end result should be the same. However the unpatched code is very
> different for the two methods, and clone may have been missing more
> functionality than the actual copy-offload was.

I think it was actually xfs, but I did look at a trace and my memory is
it was trying a CLONE and falling back on COPY.  I'll double check....

--b.

> 
> > 
> > --b.
> > 
> > > 
> > > --b.
> > > 
> > > On Wed, Apr 14, 2021 at 10:31:38AM -0400, trondmy@kernel.org wrote:
> > > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > > 
> > > > When a copy offload is performed, we do not expect the source
> > > > file to
> > > > change other than perhaps to see the atime be updated.
> > > > 
> > > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > > ---
> > > >  fs/nfs/nfs42proc.c | 7 +------
> > > >  1 file changed, 1 insertion(+), 6 deletions(-)
> > > > 
> > > > diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c
> > > > index 3875120ef3ef..a24349512ffe 100644
> > > > --- a/fs/nfs/nfs42proc.c
> > > > +++ b/fs/nfs/nfs42proc.c
> > > > @@ -390,12 +390,7 @@ static ssize_t _nfs42_proc_copy(struct file
> > > > *src,
> > > >         }
> > > >  
> > > >         nfs42_copy_dest_done(dst_inode, pos_dst, res-
> > > > >write_res.count);
> > > > -
> > > > -       spin_lock(&src_inode->i_lock);
> > > > -       nfs_set_cache_invalid(src_inode, NFS_INO_REVAL_PAGECACHE
> > > > |
> > > > -                                               
> > > > NFS_INO_REVAL_FORCED |
> > > > -                                               
> > > > NFS_INO_INVALID_ATIME);
> > > > -       spin_unlock(&src_inode->i_lock);
> > > > +       nfs_invalidate_atime(src_inode);
> > > >         status = res->write_res.count;
> > > >  out:
> > > >         if (args->sync)
> > > > -- 
> > > > 2.30.2
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com
> 
>