Date: Wed, 7 Mar 2007 23:35:55 -0500 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) Cc: freebsd-hackers@freebsd.org, Steven Hartland <killing@multiplay.co.uk> Subject: Re: NFS based /usr prevents normal startup due to slow net init Message-ID: <17903.37547.207909.316479@bhuda.mired.org> In-Reply-To: <86lki8u1al.fsf@dwp.des.no> References: <015601c75ce9$d0263a10$b3db87d4@multiplay.co.uk> <17896.23312.980989.68558@bhuda.mired.org> <86lki8u1al.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In <86lki8u1al.fsf@dwp.des.no>, Dag-Erling Smørgrav <des@des.no> typed: > Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> writes: > > Steven Hartland <killing@multiplay.co.uk> writes: > > > Another observation from my recent dealings with using > > > NFS based /usr is that the remote critical mounts via > > > nfs dont always give the network enough time to > > > initialise before running. The first error displayed > > > is: > > > Mounting NFS file systems:mount_nfs: nfs1: hostname nor servname provided, or not known > > > [...] > > How about an extra flag in your fstab? The default behavior for > > mount_nfs is to keep retrying until the mount succeeds. > > No, it will fail immediately (as seen above) if it can't resolve the > server name. The only way to fix this is to modify mount_nfs to sleep > and retry in such cases. The *current* sleep-and-retry code is in the > NFS mount code in the kernel, which doesn't come into play until after > DNS lookup. In that case, there's a bug in the mount_nfs man page, which just says that it keeps retrying until it succeeds. PR #110062 <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17903.37547.207909.316479>