Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Nov 2002 14:02:14 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        Robert Watson <rwatson@FreeBSD.ORG>, Mikhail Teterin <mi+mx@aldan.algebra.com>, current@FreeBSD.ORG
Subject:   Re: -current unusable after a crash
Message-ID:  <3DE29DE6.CDD96F3F@mindspring.com>
References:  <200211250959.39594.mi%2Bmx@aldan.algebra.com> <Pine.NEB.3.96L.1021125102358.33619A-100000@fledge.watson.org> <20021125172445.GA8953@rot13.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote:
> On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote:
> > > I thought, this might be due to the priority of the background fsck and
> > > have once left it alone for several hours -- with no effect. The usual
> > > fsck takes a few minutes.
> 
> We really need to disable background fsck if the system panicked.
> I've seen far too much bizarre filesystem behaviour that went away the
> next time I did a full fsck.

I don't think this is really possible.

I went looking for a generic "application use" CMOS are for this
sort of thing a while back, and I was unable to find one.

If you made system dumps mandatory (or marked swap with a non-dump
header in case of panic), this still would not handle the "silent
reboot", "double panic", or "single panic with disk I/O trashed"
cases.  8-(.

There was a discussion about these issues when background fsck
first went in.  My opinion of having it on by default is that if
you are going to play that loose, you might as well mount the FSs
async, and be done with it.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE29DE6.CDD96F3F>