* Mount regression between 4.0.4 client and 2.6.35 server
@ 2015-06-18 8:04 Anders Blomdell
2015-06-18 11:49 ` Trond Myklebust
0 siblings, 1 reply; 9+ messages in thread
From: Anders Blomdell @ 2015-06-18 8:04 UTC (permalink / raw)
To: linux-nfs
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server
due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See
https://bugzilla.redhat.com/show_bug.cgi?id=1228272.
Proposed patch attached.
Regards
Anders Blomdell
--
Anders Blomdell Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
[-- Attachment #2: nfs4_discover_server_trunking-eio.patch --]
[-- Type: text/x-patch, Size: 866 bytes --]
Minimum viable patch to continue version autonegotiotion in
case where the server returns an unexpected NFS4ERR_INVAL,
which happens for a 4.0.4-303.fc22.x86_64 client talking to
a 2.6.35.14-106.fc14.i686.PAE server, see
https://bugzilla.redhat.com/show_bug.cgi?id=1228272
Signed-off-by: Anders Blomdell <anders.blomdell@control.lth.se>
--- utils/mount/stropts.c.orig 2015-06-18 09:51:02.091148891 +0200
+++ utils/mount/stropts.c 2015-06-18 09:48:56.859970023 +0200
@@ -838,6 +838,10 @@ check_result:
return result;
switch (errno) {
+ case EIO:
+ /* Fix to handle nfs4_discover_server_trunking returning
+ * EIO in case where nfs server returns NFS4ERR_INVAL,
+ * see https://bugzilla.redhat.com/show_bug.cgi?id=1228272 */
case EPROTONOSUPPORT:
/* A clear indication that the server or our
* client does not support NFS version 4 and minor */
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-18 8:04 Mount regression between 4.0.4 client and 2.6.35 server Anders Blomdell @ 2015-06-18 11:49 ` Trond Myklebust 2015-06-18 12:28 ` Anders Blomdell 2015-06-26 12:17 ` Benjamin Coddington 0 siblings, 2 replies; 9+ messages in thread From: Trond Myklebust @ 2015-06-18 11:49 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux NFS Mailing List On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell <anders.blomdell@control.lth.se> wrote: > > I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server > due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See > https://bugzilla.redhat.com/show_bug.cgi?id=1228272. Why should we change the clients if the server is in clear and obvious violation of the spec? Cheers Trond ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-18 11:49 ` Trond Myklebust @ 2015-06-18 12:28 ` Anders Blomdell 2015-06-18 12:53 ` Trond Myklebust 2015-06-26 12:17 ` Benjamin Coddington 1 sibling, 1 reply; 9+ messages in thread From: Anders Blomdell @ 2015-06-18 12:28 UTC (permalink / raw) To: Trond Myklebust; +Cc: Linux NFS Mailing List On 2015-06-18 13:49, Trond Myklebust wrote: > On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell > <anders.blomdell@control.lth.se> wrote: >> >> I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server >> due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See >> https://bugzilla.redhat.com/show_bug.cgi?id=1228272. > > > Why should we change the clients if the server is in clear and obvious > violation of the spec? In order to make clients work with servers that worked well with previous versions of nfs-utils, the cultprit probably being commit f9802988 that bumped the default autonegotion version to 4.2, what the patch does is only to negotiate a lower version in case of errors, and hence making 1.3.2 working with servers that worked with 1.3.1 (that only tried version 4[.0]). Will probably save some people some time. /Anders -- Anders Blomdell Email: anders.blomdell@control.lth.se Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-18 12:28 ` Anders Blomdell @ 2015-06-18 12:53 ` Trond Myklebust 2015-06-18 14:20 ` Steve Dickson 0 siblings, 1 reply; 9+ messages in thread From: Trond Myklebust @ 2015-06-18 12:53 UTC (permalink / raw) To: Anders Blomdell; +Cc: Linux NFS Mailing List On Thu, Jun 18, 2015 at 8:28 AM, Anders Blomdell <anders.blomdell@control.lth.se> wrote: > On 2015-06-18 13:49, Trond Myklebust wrote: >> On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell >> <anders.blomdell@control.lth.se> wrote: >>> >>> I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server >>> due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See >>> https://bugzilla.redhat.com/show_bug.cgi?id=1228272. >> >> >> Why should we change the clients if the server is in clear and obvious >> violation of the spec? > In order to make clients work with servers that worked well with previous versions > of nfs-utils, the cultprit probably being commit f9802988 that bumped the default > autonegotion version to 4.2, what the patch does is only to negotiate a lower version > in case of errors, and hence making 1.3.2 working with servers that worked with > 1.3.1 (that only tried version 4[.0]). > > Will probably save some people some time. This is what /etc/nfsmount.conf is for. We don't fix clients that are working correctly according to the protocol spec. Trond ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-18 12:53 ` Trond Myklebust @ 2015-06-18 14:20 ` Steve Dickson 0 siblings, 0 replies; 9+ messages in thread From: Steve Dickson @ 2015-06-18 14:20 UTC (permalink / raw) To: Trond Myklebust, Anders Blomdell; +Cc: Linux NFS Mailing List Hello, BTW, I asked Anders to post this patch to get this discussion going. On 06/18/2015 08:53 AM, Trond Myklebust wrote: > On Thu, Jun 18, 2015 at 8:28 AM, Anders Blomdell > <anders.blomdell@control.lth.se> wrote: >> On 2015-06-18 13:49, Trond Myklebust wrote: >>> On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell >>> <anders.blomdell@control.lth.se> wrote: >>>> >>>> I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server >>>> due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1228272. >>> >>> >>> Why should we change the clients if the server is in clear and obvious >>> violation of the spec? >> In order to make clients work with servers that worked well with previous versions >> of nfs-utils, the cultprit probably being commit f9802988 that bumped the default >> autonegotion version to 4.2, what the patch does is only to negotiate a lower version >> in case of errors, and hence making 1.3.2 working with servers that worked with >> 1.3.1 (that only tried version 4[.0]). >> >> Will probably save some people some time. > > This is what /etc/nfsmount.conf is for. We don't fix clients that are > working correctly according to the protocol spec. > Using /etc/nfsmount.conf does not scale very well when there is a large number clients involved... When we bumped up the auto-negotiation to 4.2, I thinking there would be issues with legacy servers. But I was thinking obscure servers like AIX would break, not old Linux servers and possibly Solaris servers (I'm trying to check that now) Inlining the patch: --- utils/mount/stropts.c.orig 2015-06-18 09:51:02.091148891 +0200 +++ utils/mount/stropts.c 2015-06-18 09:48:56.859970023 +0200 @@ -838,6 +838,10 @@ check_result: return result; switch (errno) { + case EIO: + /* Fix to handle nfs4_discover_server_trunking returning + * EIO in case where nfs server returns NFS4ERR_INVAL, + * see https://bugzilla.redhat.com/show_bug.cgi?id=1228272 */ case EPROTONOSUPPORT: /* A clear indication that the server or our * client does not support NFS version 4 and minor */ Now I'm not sure this is the right to handle this but I do think it is a good idea to make the auto-negation mounting code smarter to handle these legacy servers. steved. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-18 11:49 ` Trond Myklebust 2015-06-18 12:28 ` Anders Blomdell @ 2015-06-26 12:17 ` Benjamin Coddington 2015-06-26 17:50 ` J. Bruce Fields 1 sibling, 1 reply; 9+ messages in thread From: Benjamin Coddington @ 2015-06-26 12:17 UTC (permalink / raw) To: Trond Myklebust; +Cc: Anders Blomdell, Linux NFS Mailing List On Thu, 18 Jun 2015, Trond Myklebust wrote: > On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell > <anders.blomdell@control.lth.se> wrote: > > > > I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server > > due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See > > https://bugzilla.redhat.com/show_bug.cgi?id=1228272. > > > Why should we change the clients if the server is in clear and obvious > violation of the spec? What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the request. Should the client's use of stateid/princ binding be optional/configureable? Ben ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-26 12:17 ` Benjamin Coddington @ 2015-06-26 17:50 ` J. Bruce Fields 2015-06-26 17:58 ` Trond Myklebust 0 siblings, 1 reply; 9+ messages in thread From: J. Bruce Fields @ 2015-06-26 17:50 UTC (permalink / raw) To: Benjamin Coddington Cc: Trond Myklebust, Anders Blomdell, Linux NFS Mailing List On Fri, Jun 26, 2015 at 08:17:30AM -0400, Benjamin Coddington wrote: > On Thu, 18 Jun 2015, Trond Myklebust wrote: > > > On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell > > <anders.blomdell@control.lth.se> wrote: > > > > > > I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server > > > due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See > > > https://bugzilla.redhat.com/show_bug.cgi?id=1228272. > > > > > > Why should we change the clients if the server is in clear and obvious > > violation of the spec? > > > What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL > for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the > request. Note that intentionally left off by default until 3.11, exactly because I thought there was a high risk of incompatibility with future clients at that point. > Should the client's use of stateid/princ binding be optional/configureable? So, perhaps there's other reasons for doing this, but we're not going to justify it for compatibility with out-of-spec behavior in older experimental server code. Possibly more annoying is that Solaris servers (I don't know which versions, I just have one report that says "Solaris 10") are also returning GARBAGE_ARGS instead of NFS4ERR_MINOR_VERS_MISMATCH on attempts to use 4.2. --b. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-26 17:50 ` J. Bruce Fields @ 2015-06-26 17:58 ` Trond Myklebust 2015-06-26 18:32 ` J. Bruce Fields 0 siblings, 1 reply; 9+ messages in thread From: Trond Myklebust @ 2015-06-26 17:58 UTC (permalink / raw) To: J. Bruce Fields Cc: Benjamin Coddington, Anders Blomdell, Linux NFS Mailing List On Fri, Jun 26, 2015 at 1:50 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Fri, Jun 26, 2015 at 08:17:30AM -0400, Benjamin Coddington wrote: >> On Thu, 18 Jun 2015, Trond Myklebust wrote: >> >> > On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell >> > <anders.blomdell@control.lth.se> wrote: >> > > >> > > I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server >> > > due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See >> > > https://bugzilla.redhat.com/show_bug.cgi?id=1228272. >> > >> > >> > Why should we change the clients if the server is in clear and obvious >> > violation of the spec? >> >> >> What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL >> for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the >> request. > > Note that intentionally left off by default until 3.11, exactly because > I thought there was a high risk of incompatibility with future clients > at that point. > >> Should the client's use of stateid/princ binding be optional/configureable? > > So, perhaps there's other reasons for doing this, but we're not going to > justify it for compatibility with out-of-spec behavior in older > experimental server code. The protocol gives the server the option of rejecting the client's request for bind_princ_stateid by simply turning off the flag in its reply. See https://tools.ietf.org/html/rfc5661#section-18.35.3 > Possibly more annoying is that Solaris servers (I don't know which > versions, I just have one report that says "Solaris 10") are also > returning GARBAGE_ARGS instead of NFS4ERR_MINOR_VERS_MISMATCH on > attempts to use 4.2. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Mount regression between 4.0.4 client and 2.6.35 server 2015-06-26 17:58 ` Trond Myklebust @ 2015-06-26 18:32 ` J. Bruce Fields 0 siblings, 0 replies; 9+ messages in thread From: J. Bruce Fields @ 2015-06-26 18:32 UTC (permalink / raw) To: Trond Myklebust Cc: Benjamin Coddington, Anders Blomdell, Linux NFS Mailing List On Fri, Jun 26, 2015 at 01:58:35PM -0400, Trond Myklebust wrote: > On Fri, Jun 26, 2015 at 1:50 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Fri, Jun 26, 2015 at 08:17:30AM -0400, Benjamin Coddington wrote: > >> On Thu, 18 Jun 2015, Trond Myklebust wrote: > >> > >> > On Thu, Jun 18, 2015 at 4:04 AM, Anders Blomdell > >> > <anders.blomdell@control.lth.se> wrote: > >> > > > >> > > I have a problem with a 4.0.4 client refusing to mount from a 2.6.35 server > >> > > due to NFS4ERR_INVAL returned during nfs4_discover_server_trunking. See > >> > > https://bugzilla.redhat.com/show_bug.cgi?id=1228272. > >> > > >> > > >> > Why should we change the clients if the server is in clear and obvious > >> > violation of the spec? > >> > >> > >> What's happening here is knfsd older than 2.6.38 will return NFS4ERR_INVAL > >> for EXCHANGE_ID that has EXCHGID4_FLAG_BIND_PRINC_STATEID set in the > >> request. > > > > Note that intentionally left off by default until 3.11, exactly because > > I thought there was a high risk of incompatibility with future clients > > at that point. > > > >> Should the client's use of stateid/princ binding be optional/configureable? > > > > So, perhaps there's other reasons for doing this, but we're not going to > > justify it for compatibility with out-of-spec behavior in older > > experimental server code. > > The protocol gives the server the option of rejecting the client's > request for bind_princ_stateid by simply turning off the flag in its > reply. See https://tools.ietf.org/html/rfc5661#section-18.35.3 Yeah, that's what it's doing. (The failure in this case was because the code just didn't know about the flag at all--I think it still had constants taken from an earlier ietf draft. Like I say, experimental code.) --b. > > > Possibly more annoying is that Solaris servers (I don't know which > > versions, I just have one report that says "Solaris 10") are also > > returning GARBAGE_ARGS instead of NFS4ERR_MINOR_VERS_MISMATCH on > > attempts to use 4.2. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-06-26 18:32 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-18 8:04 Mount regression between 4.0.4 client and 2.6.35 server Anders Blomdell 2015-06-18 11:49 ` Trond Myklebust 2015-06-18 12:28 ` Anders Blomdell 2015-06-18 12:53 ` Trond Myklebust 2015-06-18 14:20 ` Steve Dickson 2015-06-26 12:17 ` Benjamin Coddington 2015-06-26 17:50 ` J. Bruce Fields 2015-06-26 17:58 ` Trond Myklebust 2015-06-26 18:32 ` J. Bruce Fields
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.