From: Peter Staubach <staubach@redhat.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Steve Dickson <SteveD@redhat.com>, Neil Brown <neilb@suse.de>,
linux-nfs@vger.kernel.org
Subject: Re: [nfs-utils PATCH] retry on EPERM from NFSv4 mount attempt
Date: Tue, 24 Nov 2009 16:19:32 -0500 [thread overview]
Message-ID: <4B0C4DE4.1090008@redhat.com> (raw)
In-Reply-To: <20091124205616.GB29856@fieldses.org>
J. Bruce Fields wrote:
> On Tue, Nov 24, 2009 at 09:29:47AM -0500, Steve Dickson wrote:
>>
>> On 11/23/2009 06:32 PM, Neil Brown wrote:
>>> Hi,
>>> I recently packaged nfs-utils 1.2.1 for openSUSE and fairly quickly
>>> got a bug report - "-o nfsvers=3" was needed to mount NFSv3
>>> filesystems.
>>>
>>> mount.nfs in 1.2.1 will first try a v4 mount but will fall-back to v3
>>> if it gets ENOENT. This works fine.
>>> However for kernel prior to 2.6.25, you don't get ENOENT, you get
>>> EPERM.
>>> In that case the fall-back to v3 doesn't happen and you get a failure
>>> to mount.
>>>
>>> So I think we need to fall back on EPERM as well. See below.
>> I already posted this patch on the v4 mailing list
>> http://linux-nfs.org/pipermail/nfsv4/2009-November/011595.html
>> but it got shot down... at least that's how I interpreted the
>> responses...
>>
>> But I do thing we need this, since there are so many server
>> that will simple break if we don't... Agreed?
>
> My position is that servers should either a) turn off NFSv4 or b) add a
> pseudoroot, and that we should modify initscripts to make this harder to
> screw up.
>
> (For now (without automatic pseudoroot creation) we should by default be
> running rpc.nfsd with -N 4; and adding the v4 support should be
> something administrators do when they add a pseudoroot.)
>
> ((If this is really totally unfeasible, then I should quickly cue up a
> revert for the patch I have queued for 2.6.33 which changes this error
> again, to SERVERFAULT....))
>
None helps new client systems who are forced to deal with older
server deployments. It is a bad thing to force customers to change
old servers simply because they want to deploy new clients. New
systems are generally just supposed to fit into existing networks
and not have to mold those networks to fit the new client's view
of the world.
Is this such a bad patch, to account for our own short sightedness
when designing the original NFSv4 server implementation? It is
even at the user level and not in the kernel...
Thanx...
ps
next prev parent reply other threads:[~2009-11-24 21:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-23 23:32 [nfs-utils PATCH] retry on EPERM from NFSv4 mount attempt Neil Brown
[not found] ` <19211.7054.291514.185591-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-11-24 14:29 ` Steve Dickson
[not found] ` <4B0BEDDB.1010203-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-11-24 20:56 ` J. Bruce Fields
2009-11-24 21:19 ` Peter Staubach [this message]
2009-11-24 21:51 ` Neil Brown
[not found] ` <20091125085122.316f4eb3-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-11-24 21:58 ` Peter Staubach
2009-11-24 22:22 ` Neil Brown
[not found] ` <20091125092227.77735d5a-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-11-24 22:29 ` Peter Staubach
2009-11-24 22:54 ` J. Bruce Fields
2009-11-24 22:58 ` Trond Myklebust
2009-11-30 13:11 ` Steve Dickson
[not found] ` <4B13C48E.5020009-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-11-30 16:43 ` Chuck Lever
2009-11-30 17:41 ` Steve Dickson
[not found] ` <4B1403CA.8050107-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-11-30 17:52 ` Chuck Lever
2009-11-30 18:12 ` Steve Dickson
2009-11-30 18:18 ` J. Bruce Fields
2009-11-30 21:59 ` Neil Brown
[not found] ` <20091201085916.7c1bb644-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-11-30 22:13 ` J. Bruce Fields
2009-12-07 22:27 ` Steve Dickson
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=4B0C4DE4.1090008@redhat.com \
--to=staubach@redhat.com \
--cc=SteveD@redhat.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
/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