From: NeilBrown <neilb@suse.de>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Trond Myklebust <trondmy@hammerspace.com>,
"anna.schumaker\@netapp.com" <anna.schumaker@netapp.com>,
"linux-nfs\@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH
Date: Wed, 08 Jan 2020 10:16:46 +1100 [thread overview]
Message-ID: <87tv56dfhd.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20200107161536.GA944@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]
On Tue, Jan 07 2020, J. Bruce Fields wrote:
> On Fri, Dec 20, 2019 at 04:19:56PM +1100, NeilBrown wrote:
>> I was a bit surprised that nfs4_map_atomic_open_claim() exists at all,
>> but given that it did, I assumed it would be used more uniformly.
>>
>> So this all implies that Linux NFS server claimed to support NFSv4.1
>> before it actually did - which seems odd. This is just a bug (which are
>> expected), but a clear ommission.
>
> For what it's worth, I did make some attempt to keep 4.1 by default
> until 3.11 (see d109148111cd "nfsd4: support minorversion 1 by default")
> but probably could have communicated that better. This isn't the only
> blatant known issue in older code.
Ahh... thanks for that.
Looking more deeply, I see that we (SUSE) left it that way, but there is
a sysconfig option to explicitly enable NFSv4.1 service, and the
customer has explicitly enabled that.
So it is sort-of there fault.
Maybe we shouldn't have given them the option.
Anyway, it is all clear now. Thanks.
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
prev parent reply other threads:[~2020-01-07 23:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 22:47 [PATCH/RFC] NFS: handle NFSv4.1 server that doesn't support NFS4_OPEN_CLAIM_DELEG_CUR_FH NeilBrown
2019-12-18 23:47 ` Trond Myklebust
2019-12-19 2:56 ` NeilBrown
2019-12-19 5:12 ` Trond Myklebust
2019-12-19 5:39 ` NeilBrown
2019-12-19 13:24 ` Trond Myklebust
2019-12-20 5:19 ` NeilBrown
2020-01-07 16:15 ` J. Bruce Fields
2020-01-07 16:53 ` J. Bruce Fields
2020-01-07 23:16 ` NeilBrown [this message]
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=87tv56dfhd.fsf@notabene.neil.brown.name \
--to=neilb@suse.de \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--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