All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Chuck Lever <chuck.lever@oracle.com>, Neil Brown <neilb@suse.de>,
	Olga Kornievskaia <kolga@netapp.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
	Jonathan Corbet <corbet@lwn.net>, Tom Haynes <loghyr@gmail.com>,
	 linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
	 linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 5/7] fs: add an ATTR_CTIME_DLG flag
Date: Mon, 26 Aug 2024 09:16:43 -0400	[thread overview]
Message-ID: <09cab08fb871708952d0594d0f13bfb8b334bb8d.camel@kernel.org> (raw)
In-Reply-To: <20240826-glasdach-zaudern-ee3d4761973c@brauner>

On Mon, 2024-08-26 at 15:08 +0200, Christian Brauner wrote:
> On Mon, Aug 26, 2024 at 08:46:15AM GMT, Jeff Layton wrote:
> > When updating the ctime on an inode for a setattr with a multigrain
> > filesystem, we usually want to take the latest time we can get for the
> > ctime. The exception to this rule is when there is a nfsd write
> > delegation and the server is proxying timestamps from the client.
> > 
> > When nfsd gets a CB_GETATTR response, we want to update the timestamp
> > value in the inode to the values that the client is tracking. The client
> > doesn't send a ctime value (since that's always determined by the
> > exported filesystem), but it does send a mtime value. In the case where
> > it does, then we may also need to update the ctime to a value
> > commensurate with that.
> > 
> > Add a ATTR_CTIME_DELEG flag, which tells the underlying setattr
> 
> Fwiw: disconnect between commit message and actually used ATTR_CTIME_DLG.
> 

Thanks, will fix.

> > machinery to respect that value and not to set it to the current time.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> 
> Are you set on sending us on a mission to free up ATTR_* bits after
> freeing up FMODE_* bits? ;)
> 

Those aren't usually allocated from the heap, so I wouldn't bother, but
I get the jest.

> If there's going to be more ATTR_*DELEG* flags that modify the
> behavior when delegation is in effect then we could consider adding
> another unsigned int ia_deleg field to struct iattr so that you can check:
> 
> if (ia_valid & ATTR_CTIME) {
> 	if (unlikely(iattr->ia_deleg & ATTR_CTIME))
> 		// do some special stuff
> 	else
> 		// do the regular stuff
> }
> 
> or some such variant.
> 

I don't forsee other flags being needed, but you never know. For now I
wouldn't bother.

> >  fs/attr.c          | 10 +++++++++-
> >  include/linux/fs.h |  1 +
> >  2 files changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/attr.c b/fs/attr.c
> > index 7144b207e715..0eb7b228b94d 100644
> > --- a/fs/attr.c
> > +++ b/fs/attr.c
> > @@ -295,7 +295,15 @@ static void setattr_copy_mgtime(struct inode *inode, const struct iattr *attr)
> >  		return;
> >  	}
> >  
> > -	now = inode_set_ctime_current(inode);
> > +	/*
> > +	 * In the case of an update for a write delegation, we must respect
> > +	 * the value in ia_ctime and not use the current time.
> > +	 */
> > +	if (ia_valid & ATTR_CTIME_DLG)
> > +		inode_set_ctime_to_ts(inode, attr->ia_ctime);
> > +	else
> > +		now = inode_set_ctime_current(inode);
> > +
> >  	if (ia_valid & ATTR_ATIME_SET)
> >  		inode_set_atime_to_ts(inode, attr->ia_atime);
> >  	else if (ia_valid & ATTR_ATIME)
> > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > index 7c1da3c687bd..43a802b2cb0d 100644
> > --- a/include/linux/fs.h
> > +++ b/include/linux/fs.h
> > @@ -211,6 +211,7 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
> >  #define ATTR_TIMES_SET	(1 << 16)
> >  #define ATTR_TOUCH	(1 << 17)
> >  #define ATTR_DELEG	(1 << 18) /* Delegated attrs (don't break) */
> > +#define ATTR_CTIME_DLG	(1 << 19) /* Delegation in effect */
> 
> What's the interaction between ATTR_DELEG and ATTR_CTIME_DLG? I think
> that's potentially confusing.
> 

Now that you mention it, I suppose we could just key off of ATTR_DELEG
instead of declaring a new flag. That should be simpler to reason out
for everyone. I'll respin this along those lines instead.

Thanks for the review!
-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2024-08-26 13:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-26 12:46 [PATCH v2 0/7] nfsd: implement the "delstid" draft Jeff Layton
2024-08-26 12:46 ` [PATCH v2 1/7] nfsd: add pragma public to delegated timestamp types Jeff Layton
2024-08-26 12:46 ` [PATCH v2 2/7] nfs_common: make nfs4.h include generated nfs4_1.h Jeff Layton
2024-08-26 12:46 ` [PATCH v2 3/7] nfsd: add support for FATTR4_OPEN_ARGUMENTS Jeff Layton
2024-08-30  1:32   ` kernel test robot
2024-08-26 12:46 ` [PATCH v2 4/7] nfsd: implement OPEN_ARGS_SHARE_ACCESS_WANT_OPEN_XOR_DELEGATION Jeff Layton
2024-08-26 12:46 ` [PATCH v2 5/7] fs: add an ATTR_CTIME_DLG flag Jeff Layton
2024-08-26 13:08   ` Christian Brauner
2024-08-26 13:16     ` Jeff Layton [this message]
2024-08-26 12:46 ` [PATCH v2 6/7] nfsd: drop the ncf_cb_bmap field Jeff Layton
2024-08-26 12:46 ` [PATCH v2 7/7] nfsd: add support for delegated timestamps Jeff Layton

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=09cab08fb871708952d0594d0f13bfb8b334bb8d.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=anna@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=corbet@lwn.net \
    --cc=jack@suse.cz \
    --cc=kolga@netapp.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=loghyr@gmail.com \
    --cc=neilb@suse.de \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.com \
    --cc=trondmy@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.