FWIW, I vote 'yes' on the question in the last paragraph.
On Fri, 20 Jul 2001, Ian Dowse wrote:
>
> Shortly after the TI-RPC changes in -current, the default retry
> behaviour for mount_nfs was changed. Previously, mount_nfs would
> keep retrying for a long time (~1 week) if the server didn't respond,
> but since revision 1.40 of mount_nfs.c, it gives up on non-background
> mounts after one attempt.
>
> I didn't back out this change in default behaviour in my later
> commits to this file, since it seemed like a more reasonable default;
> NFS filesystems listed in fstab listed without any options can no
> longer hang the boot process waiting for the server to respond,
> and background mounts will succeed whenever the server comes up.
> I subsequently MFC'd this about 3 weeks ago.
>
> What I just remembered the other day is that there are a class of
> situations where you do want certain NFS mounts to hang the boot
> process if the server is down. These include cases where an NFS
> filesystem is critical to the boot process, so the machine will
> get stuck if it tries to proceed without it. The changes to mount_nfs
> had broken support for that situation, but I committed a fix to
> -current today that allows you to add `-R0' to the mount options
> to force mount_nfs to retry forever.
>
> So the question is - should I keep the new behaviour that is probably
> a better default and will catch out fewer new users but may surprise
> some experienced users, or should I revert to the traditional
> default where `-R1' or `-b' are required to avoid boot-time hangs?
>
> Ian
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
