On Nov 30, 2009, at 8:11 AM, Steve Dickson wrote:
Sorry for the delayed response, I took some time off...
On 11/24/2009 09:29 AM, 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?
There appears to be a consensus that we need to do something
but no agreement on what....
I believe the options are:
1) Start servers with '-N 4' when there is no root configured.
* The problem I see with this is, in the event v4 support is
wanted
its yet another configuration knob that has to be turned,
basically
making it more difficult for people use v4.
2) Change the kernel to return NFS4ERR_SERVERFAULT when there is no
root configured.
* I see this is yet another errno the mounting code has to deal
with..
We are up to two errnos, do we really want to add a third?
Neither one of these solutions deal with legacy servers or move
the "v4 technology" forward... IMHO...
To quote Yoda, "No. There is another."
Distributions can choose to revert the recently added behavior which
makes mount.nfs try vers=4 by default. That's what the mount config
file is for, yes? That seems like a responsible choice, given the
number of legacy servers still in the field.
At some later point (say, when your pseudoroot work is more widely
deployed), distributions can make vers=4 the default as shipped simply
by flipping a switch in the mount config file. For now, the default
behavior stays the same, with an option for individual sites to try
something new. In my opinion, default behavior out of the shrinkwrap
should always be the behavior most likely to work in any environment
-- principle of least surprise, and all that sort of thing.
This seems like the way we normally deploy new features like this, and
would give the many very recent changes in mount.nfs more soak time
with early adopters before we force them on everyone.
I know you won't like that idea Steve, but at least we should discuss
it before rejecting the idea out of hand.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
