From: Christoph Hellwig <hch@lst.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Christoph Hellwig <hch@lst.de>,
Trond Myklebust <trond.myklebust@primarydata.com>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2/2] nfsd: implement chage_attr_type attribute
Date: Tue, 11 Nov 2014 11:27:35 +0100 [thread overview]
Message-ID: <20141111102735.GB17313@lst.de> (raw)
In-Reply-To: <20141110175424.GC32702@fieldses.org>
On Mon, Nov 10, 2014 at 12:54:24PM -0500, J. Bruce Fields wrote:
> Shouldn't that be NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR?
>
> The draft says that e.g. "If the client sees
> NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, it has the ability to predict what
> the resulting change attribute value should be after a COMPOUND
> containing a SETATTR, WRITE, or CREATE."
>
> Admittedly, I'm not completely sure what that means. (Is a SETATTR of
> multiple attributes a single atomic change? Can we predict the change
> attribute on a newly created file, or only on the parent directory?) I
> also don't know where the filesystems do the i_version increment (can we
> guarantee it happens once per nfs WRITE?).
Actually the server may increment it many times for a single WRITE,
for XFS it is incremented for each dirty transaction, which could
happen many times during a single write:
(1) c/mtime update
(2) suid/sgid bit removal
(3) block allocation (could be multiple transactions)
So I guess we really should move to NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR
instead.
next prev parent reply other threads:[~2014-11-11 10:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-08 12:11 nfsd: add support for the chage_attr_type attribute Christoph Hellwig
2014-11-08 12:11 ` [PATCH 1/2] nfsd: correctly define v4.2 support attributes Christoph Hellwig
2014-11-10 22:21 ` J. Bruce Fields
2014-11-11 10:22 ` Christoph Hellwig
2014-11-08 12:11 ` [PATCH 2/2] nfsd: implement chage_attr_type attribute Christoph Hellwig
2014-11-10 17:54 ` J. Bruce Fields
2014-11-11 10:27 ` Christoph Hellwig [this message]
2014-11-11 12:36 ` Trond Myklebust
2014-11-11 16:27 ` Christoph Hellwig
2014-11-11 22:27 ` Dave Chinner
2014-11-12 10:24 ` Christoph Hellwig
2014-11-12 14:26 ` Trond Myklebust
2014-11-13 0:28 ` Dave Chinner
2014-11-13 13:02 ` Trond Myklebust
2014-11-13 21:47 ` Dave Chinner
2014-11-13 23:54 ` Dave Chinner
2014-11-14 0:43 ` Trond Myklebust
2014-11-14 4:35 ` Dave Chinner
2014-11-14 14:22 ` Trond Myklebust
2014-11-15 1:24 ` Dave Chinner
2014-11-11 21:42 ` J. Bruce Fields
2014-12-01 19:50 ` J. Bruce Fields
2014-12-02 17:23 ` Christoph Hellwig
2014-11-10 21:42 ` nfsd: add support for the " J. Bruce Fields
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=20141111102735.GB17313@lst.de \
--to=hch@lst.de \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
/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.