On Jul 21, 2008, at 2:06 AM, Neil Brown wrote:
On Monday July 21, chucklever@xxxxxxxxx wrote:
The workaround for older nfs-utils has been to specify
"mountproto=udp/tcp" explicitly.
Yes, that's a usable workaround.
I think this works around the problem of having a server who's
portmapper listens only on TCP. The underlying portmap client in the
mount command (and in the kernel) should be able to deal with that
without tying the rpcbind transport to the transport that is being
queried, and that is what is truly broken here.
So I think I would rather see this problem addressed in the
portmap/rpcbind client implementations and not in the upper level
mountd clients. If a portmap query doesn't work over UDP, it seems
like it should try it over TCP instead, and then remember that for
later queries.
I think your objection would be that this doesn't address the
regression for particular combinations of nfs-utils and kernel
versions, but I don't have a better suggestion at the moment.
My other objection is the you are pushing too much functionality into
the kernel.
The portmap lookup can be done in userspace, and so "should" be.
I'm not even convinced that the mount lookup belongs in the kernel,
though passing a (hex encoded) file handle down might be a bit clumsy.
But I've decided that there are bigger fish in the sea and I'm going
to let this one swim away. As you say, the enterprise releases are
more important, and it looks like enough fixes will make their way in
before SLES11 that this won't be an issue any more.
I still hope the other two nfs-utils patches will get in.
FWIW, I'm comfortable with your suggested changes to sm-notify and
with using connected UDP sockets where we can in mount.nfs.
In combination with using connected UDP sockets for kernel RPC
clients, and with the recent fixes to the kernel's mount option parser
to use appropriate transport protocol defaults, I think we will be in
much better shape.
Again, I may not be clear on the original requirements here. My
understanding is that the legacy mount command uses default settings
if "proto/mountproto" are not specified. It does not attempt to use
"the best" settings unless the default settings don't work. This is
what the text-based mount logic does -- it uses default settings
(NFSv3 over TCP, mountd v3 over UDP), then punts if it needs service
discovery.
"requirements"? that would be nice?
The legacy code tries every possibly combination of values that
weren't explicitly given until it finds a combination that "works".
It goes from most desirable to least desirable.
The text-based mount logic doesn't do what you said any more.
It default to mountd over TCP thanks to
nfs_set_mount_transport_protocol().
Will this be a regression for someone else I wonder ....
NeilBrown
--
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
--
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
