All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chandan Babu R <chandanbabu@kernel.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Jeff Layton <jlayton@kernel.org>,
	Chuck Lever <chuck.lever@oracle.com>,
	linux-nfs@vger.kernel.org, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	brauner@kernel.org
Subject: Re: [PATCH] xfs: reinstate the old i_version counter as STATX_CHANGE_COOKIE
Date: Thu, 12 Oct 2023 10:17:44 +0530	[thread overview]
Message-ID: <874jiwa06p.fsf@debian-BULLSEYE-live-builder-AMD64> (raw)
In-Reply-To: <20231011191200.GA21277@frogsfrogsfrogs>

On Wed, Oct 11, 2023 at 12:12:00 PM -0700, Darrick J. Wong wrote:
> On Wed, Oct 11, 2023 at 11:51:08AM -0400, Jeff Layton wrote:
>> On Wed, 2023-10-11 at 08:49 -0700, Darrick J. Wong wrote:
>> > On Wed, Oct 11, 2023 at 09:09:38AM -0400, Jeff Layton wrote:
>> > > On Fri, 2023-09-29 at 14:43 -0400, Jeff Layton wrote:
>> > > > The handling of STATX_CHANGE_COOKIE was moved into generic_fillattr in
>> > > > commit 0d72b92883c6 (fs: pass the request_mask to generic_fillattr), but
>> > > > we didn't account for the fact that xfs doesn't call generic_fillattr at
>> > > > all.
>> > > > 
>> > > > Make XFS report its i_version as the STATX_CHANGE_COOKIE.
>> > > > 
>> > > > Fixes: 0d72b92883c6 (fs: pass the request_mask to generic_fillattr)
>> > > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
>> > > > ---
>> > > > I had hoped to fix this in a better way with the multigrain patches, but
>> > > > it's taking longer than expected (if it even pans out at this point).
>> > > > 
>> > > > Until then, make sure we use XFS's i_version as the STATX_CHANGE_COOKIE,
>> > > > even if it's bumped due to atime updates. Too many invalidations is
>> > > > preferable to not enough.
>> > > > ---
>> > > >  fs/xfs/xfs_iops.c | 5 +++++
>> > > >  1 file changed, 5 insertions(+)
>> > > > 
>> > > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
>> > > > index 1c1e6171209d..2b3b05c28e9e 100644
>> > > > --- a/fs/xfs/xfs_iops.c
>> > > > +++ b/fs/xfs/xfs_iops.c
>> > > > @@ -584,6 +584,11 @@ xfs_vn_getattr(
>> > > >  		}
>> > > >  	}
>> > > >  
>> > > > +	if ((request_mask & STATX_CHANGE_COOKIE) && IS_I_VERSION(inode)) {
>> > > > +		stat->change_cookie = inode_query_iversion(inode);
>> > > > +		stat->result_mask |= STATX_CHANGE_COOKIE;
>> > > > +	}
>> > > > +
>> > > >  	/*
>> > > >  	 * Note: If you add another clause to set an attribute flag, please
>> > > >  	 * update attributes_mask below.
>> > > > 
>> > > > ---
>> > > > base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6
>> > > > change-id: 20230929-xfs-iversion-819fa2c18591
>> > > > 
>> > > > Best regards,
>> > > 
>> > > Ping?
>> > > 
>> > > This patch is needed in v6.6 to prevent a regression when serving XFS
>> > > via NFSD. I'd prefer this go in via the xfs tree, but let me know if
>> > > you need me to get this merged this via a different one.
>> > 
>> > Oh!   Right, this is needed because the "hide a state in the high bit of
>> > tv_nsec" stuff got reverted in -rc3, correct?  So now nfsd needs some
>> > way to know that something changed in the file, and better to have too
>> > many client invalidations than not enough?  And I guess bumping
>> > i_version will keep nfsd sane for now?
>> > 
>> > If the answers are [yes, yes, yes] then:
>> > Reviewed-by: Darrick J. Wong <djwong@kernel.org>
>> 
>> Yes, yes, and yes. Can you guys shepherd this into mainline?
>
> Chandan, can you queue this (and the other xfs fixes I sent) for -rc6?
>

I have pulled in your fixes and also the current patch. I will have to execute
fstests for atleast one day before updating xfs-linux's for-next branch.

-- 
Chandan

      reply	other threads:[~2023-10-12  5:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-29 18:43 [PATCH] xfs: reinstate the old i_version counter as STATX_CHANGE_COOKIE Jeff Layton
2023-10-11 13:09 ` Jeff Layton
2023-10-11 15:49   ` Darrick J. Wong
2023-10-11 15:51     ` Jeff Layton
2023-10-11 19:12       ` Darrick J. Wong
2023-10-12  4:47         ` Chandan Babu R [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=874jiwa06p.fsf@debian-BULLSEYE-live-builder-AMD64 \
    --to=chandanbabu@kernel.org \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=djwong@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.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 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.