Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1605860

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization

From "J. Bruce Fields" <bfields@fieldses.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization
Date 2017-03-21 19:00 +0100
Message-ID <tnweB-6BQ-1@gated-at.bofh.it> (permalink)
References (3 earlier) <tndlD-2eT-17@gated-at.bofh.it> <tnskG-3ZE-17@gated-at.bofh.it> <tnuZc-5Ru-35@gated-at.bofh.it> <tnvLz-6rG-11@gated-at.bofh.it> <tnvVg-6v1-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization bfields@fieldses.org (J. Bruce Fields) - 2017-03-20 22:50 +0100
  Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Christoph Hellwig <hch@infradead.org> - 2017-03-21 14:50 +0100
    Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-03-21 17:40 +0100
      Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and  optimization Jeff Layton <jlayton@redhat.com> - 2017-03-21 18:30 +0100
        Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-03-21 18:40 +0100
          Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-03-21 19:00 +0100
        Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and  optimization Jeff Layton <jlayton@redhat.com> - 2017-03-21 19:50 +0100
          Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-03-21 20:20 +0100
            Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and  optimization Jeff Layton <jlayton@redhat.com> - 2017-03-21 23:10 +0100
        Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization "J. Bruce Fields" <bfields@fieldses.org> - 2017-03-21 19:50 +0100
        Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and optimization Dave Chinner <david@fromorbit.com> - 2017-03-21 22:50 +0100
          Re: [RFC PATCH v1 00/30] fs: inode->i_version rework and  optimization Jeff Layton <jlayton@redhat.com> - 2017-03-22 21:00 +0100

csiph-web