[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170321175129.GC17872@fieldses.org>
Date: Tue, 21 Mar 2017 13:51:29 -0400
From: "J. Bruce Fields" <bfields@...ldses.org>
To: Jeff Layton <jlayton@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-nfs@...r.kernel.org, linux-ext4@...r.kernel.org,
linux-btrfs@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization
On Tue, Mar 21, 2017 at 01:37:04PM -0400, J. Bruce Fields wrote:
> On Tue, Mar 21, 2017 at 01:23:24PM -0400, Jeff Layton wrote:
> > On Tue, 2017-03-21 at 12:30 -0400, J. Bruce Fields wrote:
> > > - NFS doesn't actually require that it increases, but I think it
> > > should. I assume 64 bits means we don't need a discussion of
> > > wraparound.
> >
> > I thought NFS spec required that you be able to recognize old change
> > attributes so that they can be discarded. I could be wrong here though.
> > I'd have to go back and look through the spec to be sure.
>
> https://tools.ietf.org/html/rfc7862#section-10
So, I'm suggesting we implement this one:
NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR: The change attribute value
MUST monotonically increase for every atomic change to the file
attributes, data, or directory contents.
It may be a slight lie--after your patches we wouldn't actually increase
"for every atomic change". I think that's OK.
--b.
Powered by blists - more mailing lists