Date: Sat, 21 Jul 2001 11:55:20 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: tlambert2@mindspring.com, mjacob@feral.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Default retry behaviour for mount_nfs Message-ID: <200107211855.f6LItKF05260@earth.backplane.com> References: <200107202327.aa64363@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:In message <3B585C76.696F1E2A@mindspring.com>, Terry Lambert writes:
:>> FWIW, I vote that we rever to the traditional default and require
:>> -R1 or -b to avoid boot time hangs. The standard behaviour for most
:>> NFS implementations that I'm aware of would do this.
:>
:>I agree; people at work have bitched about this. We have a
:>FreeBSD NFS server that's flakey.
:
:Ok, from the small set of responses so far, it seems that the most
:acceptable option is to change mount_nfs to behave in the old way
:where it will retry forever by default even in foreground mode.
:Below is a proposed patch that does this. It also adds two paragraphs
:near the start of the manpage which describe the default behaviour
:and point readers at the relevant options. Comments welcome.
:
:>The other thing is that it appears to break amd behaviour.
:
:Does amd use mount_nfs(8)? I thought it did the mount syscalls
:directly.
:
:Ian
I'm going to throw in my two cents and agree here... backout the
change so the original behavior is restored. Generally speaking when
you have a foreground NFS mount in /etc/fstab, it's something important.
And you want background mounts to stick around 'forever' too, because
the network they are going through might take time to come up (wireless,
pccardd, dialup).
If someone doesn't want to wait for an NFS mount during boot they can
'bg' it, or 'noauto' it.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107211855.f6LItKF05260>