Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 19 Jul 2001 22:41:15 -0700 (PDT)
From:      Gordon Tetlow <gordont@gnf.org>
To:        Matthew Jacob <mjacob@feral.com>
Cc:        Ian Dowse <iedowse@maths.tcd.ie>, <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: Default retry behaviour for mount_nfs
Message-ID:  <Pine.LNX.4.33.0107192236130.26208-100000@smtp.gnf.org>
In-Reply-To: <Pine.BSF.4.21.0107192236410.73652-100000@beppo>

next in thread | previous in thread | raw e-mail | index | archive | help
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 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?Pine.LNX.4.33.0107192236130.26208-100000>