From: "bfields@fieldses.org" <bfields@fieldses.org>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"bfields@redhat.com" <bfields@redhat.com>,
"chuck.lever@oracle.com" <chuck.lever@oracle.com>
Subject: Re: [PATCH 1/6] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations
Date: Tue, 1 Dec 2020 10:19:47 -0500 [thread overview]
Message-ID: <20201201151947.GA15368@fieldses.org> (raw)
In-Reply-To: <a1db16841eb3e710a0245234c88ef2ceea2336fb.camel@hammerspace.com>
On Tue, Dec 01, 2020 at 03:23:00AM +0000, Trond Myklebust wrote:
> On Tue, 2020-12-01 at 03:16 +0000, Trond Myklebust wrote:
> > On Mon, 2020-11-30 at 22:11 -0500, bfields@fieldses.org wrote:
> > > On Tue, Dec 01, 2020 at 03:06:46AM +0000, Trond Myklebust wrote:
> > > > A local filesystem might choose to set the 'non-atomic' flag
> > > > without
> > > > wanting to turn off NFSv3 WCC attributes. Yes, the latter are
> > > > assumed
> > > > to be atomic, but a number of commercial servers do abuse that
> > > > assumption in practice.
> > >
> > > What do you mean by abusing that assumption?
> > >
> > > I thought that leaving off the post-op attrs was the v3 protocol's
> > > way
> > > of saying that it couldn't give you atomic wcc information.
> > >
> >
> > I mean that a number of commercial servers will happily return NFSv3
> > pre/post-operation WCC information that is not atomic with the
> > operation that is supposed to be 'protected'. This is, after all, why
> > the NFSv4 "struct change_info4" added the 'atomic' field in the first
> > place.
>
> BTW: To be fair, so does knfsd...
>
> At Hammerspace, we had some real problems recently due to XFS exports
> returning non-atomic values for the "space used" field. Speculative
> preallocation is a real bitch:
> https://xfs.org/index.php/XFS_FAQ#Q:_What_is_speculative_preallocation.3F
So you think xfs should omit v3 post-operation attributes and still set
the atomic bit in v4 replies?
Would that have helped in the cases you saw? It seems like speculative
preallocation isn't a problem with atomicity exactly--it couldn't be
avoided by applications cooperating with some locking scheme, for
example, if I'm understanding right.
--b.
next prev parent reply other threads:[~2020-12-01 15:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-30 21:24 [PATCH 0/6] Patches to support NFS re-exporting trondmy
2020-11-30 21:24 ` [PATCH 1/6] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations trondmy
2020-11-30 21:24 ` [PATCH 2/6] nfsd: allow filesystems to opt out of subtree checking trondmy
2020-11-30 21:24 ` [PATCH 3/6] nfsd: close cached files prior to a REMOVE or RENAME that would replace target trondmy
2020-11-30 21:24 ` [PATCH 4/6] exportfs: Add a function to return the raw output from fh_to_dentry() trondmy
2020-11-30 21:24 ` [PATCH 5/6] nfsd: Fix up nfsd to ensure that timeout errors don't result in ESTALE trondmy
2020-11-30 21:24 ` [PATCH 6/6] nfsd: Set PF_LOCAL_THROTTLE on local filesystems only trondmy
2020-11-30 23:05 ` [PATCH 5/6] nfsd: Fix up nfsd to ensure that timeout errors don't result in ESTALE J. Bruce Fields
2020-12-01 0:39 ` Trond Myklebust
2020-12-01 2:30 ` J. Bruce Fields
2020-11-30 22:59 ` [PATCH 2/6] nfsd: allow filesystems to opt out of subtree checking J. Bruce Fields
2020-11-30 22:58 ` [PATCH 1/6] nfsd: add a new EXPORT_OP_NOWCC flag to struct export_operations J. Bruce Fields
2020-12-01 0:33 ` Trond Myklebust
2020-12-01 0:45 ` Trond Myklebust
2020-12-01 2:28 ` J. Bruce Fields
2020-12-01 3:06 ` Trond Myklebust
2020-12-01 3:11 ` bfields
2020-12-01 3:16 ` Trond Myklebust
2020-12-01 3:23 ` Trond Myklebust
2020-12-01 15:19 ` bfields [this message]
2020-12-01 15:50 ` Trond Myklebust
2020-12-01 15:06 ` J. Bruce Fields
2020-12-01 19:46 ` J. Bruce Fields
2020-11-30 23:11 ` Chuck Lever
2020-12-01 0:49 ` Trond Myklebust
2020-12-01 0:14 ` Jeff Layton
2020-11-30 21:40 ` [PATCH 0/6] Patches to support NFS re-exporting Chuck Lever
2020-11-30 21:51 ` Trond Myklebust
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=20201201151947.GA15368@fieldses.org \
--to=bfields@fieldses.org \
--cc=bfields@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@hammerspace.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).