All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>,
	Anders Blomdell <anders.blomdell@control.lth.se>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Mount regression between 4.0.4 client and 2.6.35 server
Date: Thu, 18 Jun 2015 10:20:40 -0400	[thread overview]
Message-ID: <5582D3B8.7090409@RedHat.com> (raw)
In-Reply-To: <CAHQdGtQddKrKgoNiLyzJMupCYyVn=HUDGtXucYD+tzOhnmrD_Q@mail.gmail.com>

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.

  reply	other threads:[~2015-06-18 14:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

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=5582D3B8.7090409@RedHat.com \
    --to=steved@redhat.com \
    --cc=anders.blomdell@control.lth.se \
    --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.