Re: NFS local mount
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 [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS local mount
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). 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. - 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?) * overload the Pass number in fstab, nobody fscks over nfs anyway. Thoughts? -Jon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
NFS local mount
Hello, I am currently installing a machine on which I want to replace the NULL and/or UNIONFS mounts with NFS. NFS server and client on the same machine, to be exact, for jailing purposes (this seems to be the most stable). The problem is, that at the FreeBSD boot process the NFS filesystems are mounted before the NFS-related daemons are started, so I can't do this in a clean way (from /etc/fstab). Are there any objections to swap those two? I mean starting the NFS server and after that mounting the NFS filesystems? A machine can be both of them, and this way it would be nice to simply place some lines into /etc/fstab, instead of hacking with /etc/rc.local and /etc/rc.conf. Thanks, -- Attila Nagye-mail: [EMAIL PROTECTED] Budapest Polytechnic (BMF.HU) @work: +361 210 1415 (194) H-1084 Budapest, Tavaszmezo u. 15-17. cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NFS local mount
Attila Nagy wrote: Hello, I am currently installing a machine on which I want to replace the NULL and/or UNIONFS mounts with NFS. NFS server and client on the same machine, to be exact, for jailing purposes (this seems to be the most stable). The problem is, that at the FreeBSD boot process the NFS filesystems are mounted before the NFS-related daemons are started, so I can't do this in a clean way (from /etc/fstab). Are there any objections to swap those two? I mean starting the NFS server and after that mounting the NFS filesystems? That would be nice since I have a problem here at WorldGate where a number of machines mount drives from eachother. If only one of them goes down at a time things are fine, but after a power outage they all block trying to mount each other and thus never start up the NFS server such that they can mount each other. My solution has been to have the NFS mounts happen as a background process and thus letting the rest of the network startup run and thus getting to start the NFS servers which then answer these background NFS mount requests. 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 :-) -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
