Date: Fri, 20 Jul 2001 01:34:34 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: freebsd-hackers@freebsd.org Subject: Default retry behaviour for mount_nfs Message-ID: <200107200134.aa51462@salmon.maths.tcd.ie>
next in thread | raw e-mail | index | archive | help
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 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? <200107200134.aa51462>