From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C45A8C28B2B for ; Thu, 18 Aug 2022 11:01:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243617AbiHRLBG (ORCPT ); Thu, 18 Aug 2022 07:01:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240270AbiHRLBF (ORCPT ); Thu, 18 Aug 2022 07:01:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B2CF97D64; Thu, 18 Aug 2022 04:01:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 28632B8214A; Thu, 18 Aug 2022 11:01:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1FD3DC433C1; Thu, 18 Aug 2022 11:00:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1660820458; bh=BJ9jTJMSUZzXkT+DShf3+Vd6Whwr/ZEx748U0LZgPQ8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=qy3yjV6lCpwWA0WKIPLxfSe7qgVUn95t+nHcrj6OEr4CFtmS2MkHcRgEe54X3eG+x 3cr6G6Hd+NweXZ43gxA4KXnn1b8YUdZwuh8BQhN/+aA+m5/fVOaIkqRIseecDd3IyQ yEvAraJktMoqlorBj6QJB1+Q0X4pqNODCqMC2v0AOHUSEVcSJO2uPe6EQVlDV1/eCp xbjxjT0H77Dejz/s1OC/1QDm1JL0EYLpvLQs4R2c4rq+Bqpg3sT5KjOPxevjYdLLLD OUlKuDJ+voQNwqDOUlJVmrYQcdT5tsO2HTcAGYJQia2FH0/oPdqSAbVPCujB/CfoiW szqz0Z3201s9w== Message-ID: Subject: Re: [PATCH] xfs: fix i_version handling in xfs From: Jeff Layton To: NeilBrown , Dave Chinner Cc: "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" Date: Thu, 18 Aug 2022 07:00:56 -0400 In-Reply-To: <166078288043.5425.8131814891435481157@noble.neil.brown.name> References: <20220816131736.42615-1-jlayton@kernel.org> , , , <20220816224257.GV3600936@dread.disaster.area> <166078288043.5425.8131814891435481157@noble.neil.brown.name> Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-1.fc36) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, 2022-08-18 at 10:34 +1000, NeilBrown wrote: > On Wed, 17 Aug 2022, Dave Chinner wrote: > >=20 > > In XFS, we've defined the on-disk i_version field to mean > > "increments with any persistent inode data or metadata change", > > regardless of what the high level applications that use i_version > > might actually require. > >=20 > > That some network filesystem might only need a subset of the > > metadata to be covered by i_version is largely irrelevant - if we > > don't cover every persistent inode metadata change with i_version, > > then applications that *need* stuff like atime change notification > > can't be supported. >=20 > So what you are saying is that the i_version provided by XFS does not > match the changeid semantics required by NFSv4. Fair enough. I guess > we shouldn't use the one to implement the other then. >=20 > Maybe we should just go back to using ctime. ctime is *exactly* what > NFSv4 wants, as long as its granularity is sufficient to catch every > single change. Presumably XFS doesn't try to ensure this. How hard > would it be to get any ctime update to add at least one nanosecond? > This would be enabled by a mount option, or possibly be a direct request > from nfsd. >=20 I think that would be an unfortunate outcome, but if we can't stop xfs from bumping the i_version on atime updates, then we may have no choice but to do so. I suppose we could add a fetch_iversion for xfs that takes it back to using the ctime. > NFSv4 changeid is really one of the more horrible parts of the > design >=20 Hah! I was telling Tom Talpey yesterday that I thought that the change counter was one of the best ideas in NFSv4 and that we should be trying to get all filesystems to implement it correctly. The part that does suck about the design is that the original specs weren't specific enough about its behavior. I think that's been somewhat remedied in more recent RFCs though. --=20 Jeff Layton