Date: Mon, 23 Jul 2001 07:38:46 -0400 From: Michael Sinz <msinz@wgate.com> To: Jonathan Chen <jon@FreeBSD.ORG> Cc: Attila Nagy <bra@fsn.hu>, freebsd-hackers@FreeBSD.ORG Subject: Re: NFS local mount Message-ID: <3B5C0CC6.EF1A3828@wgate.com> References: <20010719155719.N45187-100000@scribble.fsn.hu> <3B57290F.15C009A5@wgate.com> <20010721145747.B59221@enterprise.spock.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jonathan Chen wrote: > > On Thu, Jul 19, 2001 at 02:38:07PM -0400, Michael Sinz wrote: > > I had been meaning to ask if there was a reason why NFS mounts happened > > before NFS servers were started but life kept getting in the way :-) > > If /usr was nfs mounted on a machine, then /usr needs to be mounted before > nfsd was loaded, and portmap/rpcgen lives in /usr and nfsd requires one of > those. Not to mention there are probably other services loaded before nfsd > which may require nfs moutned directories. In general, it is a good idea > to first setup vital parts of the system (like networking or mounting > directories) before offering other services (such as nfsd). Ahh, but a auto-backgrounding of NFS mounts would be nice. In (albeit old) SYSV R4 which we (my old Commodore hat) did on the Amiga UNIX project, NFS mounts would try for a bit at boot time and then switch into the background if they took too long. One could specifically ask for a mount to be hard such that it would not background under any conditions. Under normal conditions, the system had its mounts up before the rest of the RC process ran. Under poor conditions, it may end up waiting for some reasonable amount of time (was it 1 or 2 minutes - I can not remember) and then background any mounts that had not yet worked. This always let the system come up to at least admin capable level, which is important when you have a headless machine somewhere. > Possible ways to fix this includes: > - do nothing, let those who run these circular nfs-mount systems fix it > themselves. Perhaps recommend -o bg in the handbook or something. That may be good - I still think some form of timeout and then bg option would be even better... > - setup a flag, nfs_mount_delayed="YES|NO" in rc.conf > - do something in fstab which distingushes nfs mounts which can be delayed > * a new nfs_delayed fstype [this screams EVILE HACK!], or > * a new "delayable" option (how's that different from bg?) I see that as the timeout before bg - where it tries and tries but after some point says "hey, it still is not up, lets bg this thing" > * overload the Pass number in fstab, nobody fscks over nfs anyway. I hate that - it feels soo bad. However, it also happens to be a good place to put in a configurable timeout for bg operation. Arg.... Don't do it - must not go to the dark side. -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. 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?3B5C0CC6.EF1A3828>