| Message ID | 55827B8D.3070103@control.lth.se (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 */