Date: Wed, 07 Mar 2007 23:38:42 +0100 From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> 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: <86lki8u1al.fsf@dwp.des.no> In-Reply-To: <17896.23312.980989.68558@bhuda.mired.org> (Mike Meyer's message of "Fri, 2 Mar 2007 12:12:48 -0500") References: <015601c75ce9$d0263a10$b3db87d4@multiplay.co.uk> <17896.23312.980989.68558@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 provid= ed, 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. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86lki8u1al.fsf>