public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Olga Kornievskaia <aglo@umich.edu>,
	Olga Kornievskaia <okorniev@redhat.com>
Cc: trond.myklebust@hammerspace.com, anna@kernel.org,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/1] NFSv4.2: fix COPY attrs in presence of delegated timestamps
Date: Fri, 03 Apr 2026 09:43:08 -0400	[thread overview]
Message-ID: <aa2e8cf9225a2a4a49fdb7db24c0e817e1b962b1.camel@kernel.org> (raw)
In-Reply-To: <CAN-5tyGJ5Y4h8iKq-F_AqYR0a8U8NrO2xk9hCG1AaJWJabW+-Q@mail.gmail.com>

On Fri, 2026-03-27 at 13:08 -0400, Olga Kornievskaia wrote:
> On Fri, Mar 27, 2026 at 12:58 PM Olga Kornievskaia <okorniev@redhat.com> wrote:
> > 
> > A similar to generic/407 test can be done with a COPY operation
> > instead of CLONE (reflink). And it leads to same problem that ctime
> > and mtime saved before doing a "cp" operation are the same as after.
> 
> Some extra comments here.
> 
> Currently the COPY compound does not add a GETATTR after the COPY.
> Jeff's solution to REMOVEXATTR not updating ctime was to add GETATTR
> to the compound and then call update attributes. This could be the
> alternative solution here instead. I'm not sure such an approach would
> be preferred. But then there is a question of whether or not the
> server does update its attributes on COPY.
> 

I think that'd ultimately be more efficient, and I think the server
should be updating the c/mtime on COPY, even if there is an outstanding
timestamp delegation. The server is doing the COPY. The client isn't
really involved so why should it be trying to stamp the file?

A GETATTR is cheap and in this case, the inode will even likely be in
cache on the server. We might as well update the attributes without
forcing another round trip in this case, since we pretty much know that
they will have changed.

If the server isn't updating its attrs on COPY in this case, then it's
probably because we're using the open file description in the
destination stateid and it has FMODE_NOCMTIME set. We can probably fix
this by just turning that flag off while the copy is running, and then
reenabling it before returning.


> > Signed-off-by: Olga Kornievskaia <okorniev@redhat.com>
> > ---
> >  fs/nfs/nfs42proc.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c
> > index f77372a78be7..ea420dc94875 100644
> > --- a/fs/nfs/nfs42proc.c
> > +++ b/fs/nfs/nfs42proc.c
> > @@ -502,6 +502,12 @@ static ssize_t _nfs42_proc_copy(struct file *src,
> > 
> >         nfs42_copy_dest_done(dst, pos_dst, res->write_res.count, oldsize_dst);
> >         nfs_invalidate_atime(src_inode);
> > +       if (nfs_have_delegated_attributes(dst_inode)) {
> > +               nfs_update_delegated_mtime(dst_inode);
> > +               spin_lock(&dst_inode->i_lock);
> > +               nfs_set_cache_invalid(dst_inode, NFS_INO_INVALID_BLOCKS);
> > +               spin_unlock(&dst_inode->i_lock);
> > +       }
> >         status = res->write_res.count;
> >  out:
> >         if (args->sync)
> > --
> > 2.52.0
> > 
> > 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2026-04-03 13:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-27 16:57 [PATCH 1/1] NFSv4.2: fix COPY attrs in presence of delegated timestamps Olga Kornievskaia
2026-03-27 17:08 ` Olga Kornievskaia
2026-04-03 13:43   ` Jeff Layton [this message]
2026-04-08 19:05 ` Olga Kornievskaia
2026-04-13 21:23 ` Trond Myklebust

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=aa2e8cf9225a2a4a49fdb7db24c0e817e1b962b1.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=aglo@umich.edu \
    --cc=anna@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=okorniev@redhat.com \
    --cc=trond.myklebust@hammerspace.com \
    /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