Bug 27383

Summary:	Client NFS mount hangs with multihomed server
Product:	Base System	Reporter:	quinot <quinot>
Component:	kern	Assignee:	iedowse
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description quinot 2001-05-16 14:00:01 UTC

	The problem is the one described in kern/9612: a FreeBSD
	NFS client hangs in sbwait() while trying to mount an NFS
	filesystem if the source address in the NFS reply is not the
	same as the destination address that was used to send the request.

	kern/9612 indicates that the server setup can be changed to
	resolve the problem, by having nfsd bind separately on each
	interface, but this assumes that the server is a FreeBSD host,
	and that its setup can be changed.

	Is there a possibility to fix the FreeBSD client side so at least
	the NFs mount can be cancelled instead of hanging indefinitely
	in sbwait?

Comment 1 iedowse 2001-05-16 14:20:46 UTC

In message <20010516125546.2F7CED5ED@geveor.cuivre.fr.eu.org>, quinot@cuivre.fr
.eu.org writes:
>
>	Is there a possibility to fix the FreeBSD client side so at least
>	the NFs mount can be cancelled instead of hanging indefinitely
>	in sbwait?

Yes, I was just looking into this a few days ago. The mount_nfs in
-current does not have this problem any longer; it now never issues
the mount() syscall until it has successfully received a response
from the remote nfsd.

There's a (very lightly tested) backport of these changes at:

	http://www.maths.tcd.ie/~iedowse/FreeBSD/mount_nfs.releng_4.diff

I would be very interested in hearing if this patch improves the
situation for you.

Ian

Comment 2 Thomas Quinot 2001-05-17 13:48:46 UTC

Le 2001-05-16, Ian Dowse écrivait :

> 	http://www.maths.tcd.ie/~iedowse/FreeBSD/mount_nfs.releng_4.diff
> I would be very interested in hearing if this patch improves the
> situation for you.

Tried it, no change. I still end up with:

    0  2445     1   0   2  0   388  240 sbwait D     p2    0:00.01 nfs infres2.enst.fr:/home/ir1 /infres/ir1 (mount_nfs)

Thomas.

Comment 3 iedowse 2001-05-17 15:00:52 UTC

In message <20010517144846.A2498@geveor.cuivre.fr.eu.org>, Thomas Quinot writes
:
>Tried it, no change. I still end up with:
>
>    0  2445     1   0   2  0   388  240 sbwait D     p2    0:00.01 nfs infres2
>.enst.fr:/home/ir1 /infres/ir1 (mount_nfs)

Bah, I see the problem, and it affects -current too. The RPC library
does not use connect() on UDP client sockets, so it will happily
accept the remote nfsd's reply, even though it comes from the wrong
address. The kernel NFS code does use connect(), so it can't see
the replies.

I'll have a look later to see how easy it would be to make the RPC
library's behaviour in this area more controllable.

Ian

Comment 4 iedowse freebsd_committer

2001-05-19 19:11:53 UTC

Responsible Changed
From-To: freebsd-bugs->iedowse

I'll deal with this issue.

Comment 5 iedowse freebsd_committer

2001-06-29 22:31:20 UTC

State Changed
From-To: open->feedback


This issue should now be properly fixed in both -current and -stable. 
Could you try updating and verify that you no longer end up with 
hung mounts when the server replies from the wrong address? Make 
sure you have revision 1.36.2.2 of src/sbin/mount_nfs/mount_nfs.c 
- I just committed it a few minutes ago.

Comment 6 iedowse freebsd_committer

2001-07-06 11:18:52 UTC

State Changed
From-To: feedback->closed


Originator has confirmed that the issue is now resolved. Thanks 
for the bug report!