linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Wed, 14 Apr 2021 16:15:38 -0400	[thread overview]
Message-ID: <20210414201538.GF16800@fieldses.org> (raw)
In-Reply-To: <20210414172825.GE16800@fieldses.org>

On Wed, Apr 14, 2021 at 01:28:25PM -0400, bfields@fieldses.org wrote:
> 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....

Yes, confirmed.  At least on my test server's distro (Fedora 28) xfs
doesn't seem to be enabling it by default.  I recreated the filesystems
with "mkfs.xfs -f -mreflink=1 /dev/vdf" and generic/430 is still passing
with your patches.

--b.


> 
> --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
> > 
> > 

      reply	other threads:[~2021-04-14 20:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-14 14:31 [PATCH 1/2] NFSv42: Copy offload should update the file size when appropriate trondmy
2021-04-14 14:31 ` [PATCH 2/2] NFSv42: Don't force attribute revalidation of the copy offload source trondmy
2021-04-14 14:40   ` J. Bruce Fields
2021-04-14 17:05     ` J. Bruce Fields
2021-04-14 17:23       ` Trond Myklebust
2021-04-14 17:28         ` bfields
2021-04-14 20:15           ` bfields [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210414201538.GF16800@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=kolga@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@hammerspace.com \
    --cc=trondmy@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).