Re: Default retry behaviour for mount_nfs
: :In message <[EMAIL PROTECTED]>, Terry Lambert writes: :>> FWIW, I vote that we rever to the traditional default and require :>> -R1 or -b to avoid boot time hangs. The standard behaviour for most :>> NFS implementations that I'm aware of would do this. :> :>I agree; people at work have bitched about this. We have a :>FreeBSD NFS server that's flakey. : :Ok, from the small set of responses so far, it seems that the most :acceptable option is to change mount_nfs to behave in the old way :where it will retry forever by default even in foreground mode. :Below is a proposed patch that does this. It also adds two paragraphs :near the start of the manpage which describe the default behaviour :and point readers at the relevant options. Comments welcome. : :>The other thing is that it appears to break amd behaviour. : :Does amd use mount_nfs(8)? I thought it did the mount syscalls :directly. : :Ian I'm going to throw in my two cents and agree here... backout the change so the original behavior is restored. Generally speaking when you have a foreground NFS mount in /etc/fstab, it's something important. And you want background mounts to stick around 'forever' too, because the network they are going through might take time to come up (wireless, pccardd, dialup). If someone doesn't want to wait for an NFS mount during boot they can 'bg' it, or 'noauto' it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
Ian Dowse wrote: > > In message <[EMAIL PROTECTED]>, Terry Lambert writes: > >> FWIW, I vote that we rever to the traditional default and require > >> -R1 or -b to avoid boot time hangs. The standard behaviour for most > >> NFS implementations that I'm aware of would do this. > > > >I agree; people at work have bitched about this. We have a > >FreeBSD NFS server that's flakey. > > Ok, from the small set of responses so far, it seems that the most > acceptable option is to change mount_nfs to behave in the old way > where it will retry forever by default even in foreground mode. > Below is a proposed patch that does this. It also adds two paragraphs > near the start of the manpage which describe the default behaviour > and point readers at the relevant options. Comments welcome. > > >The other thing is that it appears to break amd behaviour. > > Does amd use mount_nfs(8)? I thought it did the mount syscalls > directly. I don't care to understand the bowels of amd, since I see enough of their product... 8-|. But it seems the behaviour changed between 4.3 and later, and it's been a problem (things like "cd" time out instead of waiting until they can get a good grip on the NFS server. Very frustrating, when your CVS tree or home directory lives on another machine. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
In message <[EMAIL PROTECTED]>, Terry Lambert writes: >> FWIW, I vote that we rever to the traditional default and require >> -R1 or -b to avoid boot time hangs. The standard behaviour for most >> NFS implementations that I'm aware of would do this. > >I agree; people at work have bitched about this. We have a >FreeBSD NFS server that's flakey. Ok, from the small set of responses so far, it seems that the most acceptable option is to change mount_nfs to behave in the old way where it will retry forever by default even in foreground mode. Below is a proposed patch that does this. It also adds two paragraphs near the start of the manpage which describe the default behaviour and point readers at the relevant options. Comments welcome. >The other thing is that it appears to break amd behaviour. Does amd use mount_nfs(8)? I thought it did the mount syscalls directly. Ian Index: mount_nfs.8 === RCS file: /dump/FreeBSD-CVS/src/sbin/mount_nfs/mount_nfs.8,v retrieving revision 1.27 diff -u -r1.27 mount_nfs.8 --- mount_nfs.8 2001/07/19 21:11:48 1.27 +++ mount_nfs.8 2001/07/20 22:20:35 @@ -71,6 +71,28 @@ .%T "NFS: Network File System Version 3 Protocol Specification" , Appendix I. .Pp +By default, +.Nm +keeps retrying until the mount eventually succeeds. +This behaviour is intended for filesystems listed in +.Xr fstab 5 +that are critical to the boot process. +For non-critical filesystems, the +.Fl R +and +.Fl b +flags provide mechanisms to prevent the boot process from hanging +if the server is unavailable. +.Pp +If the server becomes unresponsive while an NFS filesystem is +mounted, any new or outstanding file operations on that filesystem +will hang uninterruptibly until the server comes back. +To modify this default behaviour, see the +.Fl i +and +.Fl s +flags. +.Pp The options are: .Bl -tag -width indent .It Fl 2 @@ -126,12 +148,8 @@ help, but for normal desktop clients this does not apply.) .It Fl R Set the mount retry count to the specified value. -A retry count of zero means to keep retrying forever. -By default, -.Nm -retries forever on background mounts (see the -.Fl b -option), and otherwise tries just once. +The default is a retry count of zero, which means to keep retrying +forever. There is a 60 second delay between each attempt. .It Fl T Use TCP transport instead of UDP. Index: mount_nfs.c === RCS file: /dump/FreeBSD-CVS/src/sbin/mount_nfs/mount_nfs.c,v retrieving revision 1.45 diff -u -r1.45 mount_nfs.c --- mount_nfs.c 2001/07/19 21:11:48 1.45 +++ mount_nfs.c 2001/07/20 21:37:19 @@ -486,7 +486,8 @@ name = *argv; if (retrycnt == -1) - retrycnt = (opflags & BGRND) ? 0 : 1; + /* The default is to keep retrying forever. */ + retrycnt = 0; if (!getnfsargs(spec, nfsargsp)) exit(1); To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] POLA? (was Re: Default retry behaviour for mount_nfs)
On Fri, 20 Jul 2001, Matthew Jacob wrote: > > I'll leave it up to you all to imagine what 'wtf WTF' is. > We all know it stands for "what's that for?"... :) Laurence Berland http://www.isp.northwestern.edu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] POLA? (was Re: Default retry behaviour for mount_nfs)
Bill Moran wrote: > > > > > Sometimes the stick of POLA should be broken. > > Off topic, I know, but it's going to bother me. > > What's POLA? Policy Of Least Astonishment -- doing changes in a way which will annoy the least number of users. HTH -Christoph Sold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] POLA? (was Re: Default retry behaviour for mount_nfs)
'Principle of Least Astonishment' and something we should import from NetBSD: pilt > uname -a NetBSD pilt 1.5.1_ALPHA NetBSD 1.5.1_ALPHA (PILT) #5: Thu Feb 8 12:01:03 PST 2001 mjacob@pilt:/export/src/NetBSD-1.5/syssrc/sys/arch/i386/compile/PILT i386 pilt > /usr/games/wtf POLA POLA: principle of least astonishment pilt > /usr/games/wtf IIRC IIRC: if I recall correctly I'll leave it up to you all to imagine what 'wtf WTF' is. On Fri, 20 Jul 2001, Bill Moran wrote: > > > > > Sometimes the stick of POLA should be broken. > > Off topic, I know, but it's going to bother me. > > What's POLA? > > -Bill > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[OT] POLA? (was Re: Default retry behaviour for mount_nfs)
> > > Sometimes the stick of POLA should be broken. Off topic, I know, but it's going to bother me. What's POLA? -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
Matthew Jacob wrote: > > Hmm, maybe we should implement the notion of "critical_local" and > > "critical_net" filesystems (a la NetBSD). Heck, I don't even need the > > distinction between net and local, just critical would do. All remote, > > critical filesystems would be blocking, and all others not. > > > > Sometimes the stick of POLA should be broken. > > Not if it adds work. I think the non-critical ones are the ones with the "-R1" option set... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
> Matthew Jacob wrote: > > > 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? > > > > > > > Sorry- let me be clearer: > > > > FWIW, I vote that we rever to the traditional default and require > > -R1 or -b to avoid boot time hangs. The standard behaviour for most > > NFS implementations that I'm aware of would do this. > > I agree; people at work have bitched about this. We have a > FreeBSD NFS server that's flakey. > > The other thing is that it appears to break amd behaviour. > > (I couldn't tell which of the two questions he was voting > in favor of, either, since there is one before the "or" and > one after). That's why I submitted a followup after Ian poked me. It's funny- I tend to think of myself as being totally transparent. Why should I need to explain what I meant then? :-) -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
Matthew Jacob wrote: > > 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? > > > > Sorry- let me be clearer: > > FWIW, I vote that we rever to the traditional default and require > -R1 or -b to avoid boot time hangs. The standard behaviour for most > NFS implementations that I'm aware of would do this. I agree; people at work have bitched about this. We have a FreeBSD NFS server that's flakey. The other thing is that it appears to break amd behaviour. (I couldn't tell which of the two questions he was voting in favor of, either, since there is one before the "or" and one after). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
> > Hmm, I don't believe so. It was a temporary network glitch (damn flaky > distribution switch) and the user wasn't able to login via xdm (his home > directory was on the NFS partition in question). > > > > I personally think the non-blocking behavior is better. > > > > In some cases, yes, in some cases, no. It's POLA to change it. > > If I don't care about an FS, I'll set it to be -bg. > > Hmm, maybe we should implement the notion of "critical_local" and > "critical_net" filesystems (a la NetBSD). Heck, I don't even need the > distinction between net and local, just critical would do. All remote, > critical filesystems would be blocking, and all others not. > > Sometimes the stick of POLA should be broken. Not if it adds work. Oddly enough, one of the few virtues BSD Unix has is that it's very conservative. Well, we could argue this forever- and both of us would be right! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
On Thu, 19 Jul 2001, Matthew Jacob wrote: > > On Thu, 19 Jul 2001, Gordon Tetlow wrote: > > > On Thu, 19 Jul 2001, Matthew Jacob wrote: > > > > > > 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? > > > > > > > > > > Sorry- let me be clearer: > > > > > > FWIW, I vote that we rever to the traditional default and require -R1 or -b to > > > avoid boot time hangs. The standard behaviour for most NFS implementations > > > that I'm aware of would do this. > > > > I was playing with a RedHat 7.1 box (kernel 2.4.x) and it continued along > > after it failed to mount and NFS server. > > Did it background? Hmm, I don't believe so. It was a temporary network glitch (damn flaky distribution switch) and the user wasn't able to login via xdm (his home directory was on the NFS partition in question). > > I personally think the non-blocking behavior is better. > > In some cases, yes, in some cases, no. It's POLA to change it. > If I don't care about an FS, I'll set it to be -bg. Hmm, maybe we should implement the notion of "critical_local" and "critical_net" filesystems (a la NetBSD). Heck, I don't even need the distinction between net and local, just critical would do. All remote, critical filesystems would be blocking, and all others not. Sometimes the stick of POLA should be broken. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
On Thu, 19 Jul 2001, Gordon Tetlow wrote: > On Thu, 19 Jul 2001, Matthew Jacob wrote: > > > > > > > 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? > > > > > > > Sorry- let me be clearer: > > > > FWIW, I vote that we rever to the traditional default and require -R1 or -b to > > avoid boot time hangs. The standard behaviour for most NFS implementations > > that I'm aware of would do this. > > I was playing with a RedHat 7.1 box (kernel 2.4.x) and it continued along > after it failed to mount and NFS server. Did it background? > I personally think the non-blocking behavior is better. In some cases, yes, in some cases, no. It's POLA to change it. If I don't care about an FS, I'll set it to be -bg. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
On Thu, 19 Jul 2001, Matthew Jacob wrote: > > > > 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? > > > > Sorry- let me be clearer: > > FWIW, I vote that we rever to the traditional default and require -R1 or -b to > avoid boot time hangs. The standard behaviour for most NFS implementations > that I'm aware of would do this. I was playing with a RedHat 7.1 box (kernel 2.4.x) and it continued along after it failed to mount and NFS server. I personally think the non-blocking behavior is better. -gordon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
> > 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? > Sorry- let me be clearer: FWIW, I vote that we rever to the traditional default and require -R1 or -b to avoid boot time hangs. The standard behaviour for most NFS implementations that I'm aware of would do this. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Default retry behaviour for mount_nfs
FWIW, I vote 'yes' on the question in the last paragraph. On Fri, 20 Jul 2001, Ian Dowse wrote: > > 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 [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
