On Nov 30, 2009, at 12:41 PM, Steve Dickson wrote:
On 11/30/2009 11:43 AM, Chuck Lever wrote:
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.
Yes... That was the main reason for the configuration file.
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.
Not matter how or when we flip the switch, we'll have to deal
with the legacy servers...
Well, the point of waiting would be so that the proportion of legacy
servers would become relatively insignificant. And, a number of
reasonable longer term solutions which have been proposed here could
be deployed in the meantime.
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.
Take a look at the Fedora 12... Its set up exactly as you just
described
with only difference vers=3 is set in the configuration file...
Perhaps that should be the upstream default as well, for now, so other
distributors aren't taken by surprise when they update to 1.2.1. Just
a thought.
--
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
