Hi,
I am using intensively mountprog= and nfsprog= options (because I tunnel nfs).
I have a redhat 7.3 kernel 2.4.18, mount-2.11n.
Suppose I have this entry in fstab
localhost:/fs /fs nfs rw,mountprog=201000,nfsprog=200005
I found that there are problems in 2 (unrelated ?) cases:
First case:
On localhost I start an nfs server which sets these 2 programs. rpcinfo -p
gives something like:
201000 3 udp 1024
200003 3 udp 1024
I mount /fs, everything is fine. Now if I restart the nfs server on localhost
such that it uses another port
(rpcinfo -p gives something like:
201000 3 udp 1025
200003 3 udp 1025)
All operation on /fs now hangs. From my readings of mount code, mount just
give to the nfs client in kernel a filehandle corresponding with a port.
Thus the nfs client cannot rebind to the new port, because it doesn't know
the rpc program.
And if the nfs server reopens the port 1024, then it goes fine again (and I
guess that any program opening this port will receive the nfs packets).
I think this is known, and I assume that it isn't easy to fix, because it
would mean adding the program to the handle mount gives to the kernel, and
having the program as an argument everywhere.
The second problem is as follow:
suppose the nfs server only registered the mount program, such that rpcinfo -p
gives:
201000 3 udp 1025
Then mount /fs hangs. I think that it isn't normal, as it should better
exit saying 200005 not registered. But what seems even more abnormal, is
that if you register the nfsprog afterwards, it still hangs. Even kill -9
doesn't take it away from the process list.
Once both programs are registered new mount /fs work, though.
Pat
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Sep 06, 2002 at 06:13:13PM +0200, Patrice DUMAS - DOCT wrote:
> Hi,
>
> I am using intensively mountprog= and nfsprog= options (because I tunnel nfs).
> I have a redhat 7.3 kernel 2.4.18, mount-2.11n.
I follow up on my own post, as I found the reason of all that, and also a
simpler case in which such a bad thing could happen.
Suppose you have started mountd on the server, but not yet nfsd, and then,
on a client you mount a filesystem from the server. As 100003 is not allready
registered, mount returns 2049 as port. The nfs client is stuck because
nfsd isn't allready started. Now imagine that you start nfsd on the server
on another port that 2049. The nfs client will never rebind with portmap,
and get stuck forever.
I think that setting autobind for the nfs client should be enough ?
Maybe if it is still required to use 2049 as port when portmap fails, it
could be possible to add a field to the rpc_client, like default_port, and
if portmap binding fails, instead of returning a bad status, set the port
to that default_port (in pmap_getport_done). Does it looks right ?
Pat
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs