Skip site navigation (1)Skip section navigation (2)
Date:      12 May 2003 20:38:05 +1000
From:      Q <q_dolan@yahoo.com.au>
To:        =?UTF-8?Q?=E6=9D=8E?= =?UTF-8?Q?=E9=91=AB?= Xin LI <delphij@freebsdchina.org>
Cc:        current@freebsd.org
Subject:   RE: Regression observations & misc errata
Message-ID:  <1052735884.8033.35.camel@boxster.home.net>
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAyh5gHFZXek2W21nd08o9XcKAAAAQAAAAR8YQhAW570m812JGAiidjwEAAAAA@freebsdchina.org>
References:   <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAyh5gHFZXek2W21nd08o9XcKAAAAQAAAAR8YQhAW570m812JGAiidjwEAAAAA@freebsdchina.org>

next in thread | previous in thread | raw e-mail | index | archive | help
That sounds like a very good idea. If you can maintain state somewhere
(safely) about whether the last fsck completed fully, you could force a
foreground "safe mode" run the next time around. This would prevent the
problem I experienced from causing repeated panics, and still allow
bgfsck to function as expected when everything is operating normally.

Seeya...Q

On Mon, 2003-05-12 at 19:43, 李鑫 Xin LI wrote:
> Ah... Sorry, it was my fault that I didn't have mentioned that the
> inconsistency seemed to be the cause of kernel panic across system crashes.
> I should have explained that the kernel panic in subsequent everyday running
> is caused by unexpected inconsistency, which in a soft update enabled
> environment, should only be a result of hardware error. I agree that we
> should take software bug, especially kernel bugs, which in many situations
> cause a kernel panic, may also generate an unexpected inconsistency, in to
> account.
> 
> I forgot to mention that after there's an fs related kernel panic, or, the
> on-disk file system image will most likely to be damaged. This is not
> frequent, however, still possible to trigger in certain situations, for
> example, some of the vm, device driver changes, will occasionally affect
> soft updates. Thanks to the talent committers, the FreeBSD project is
> efficient, for these bugs are usually fixed as soon as someone discovered
> them.
> 
> I have got an (silly?) idea to work around this problem: before background
> fsck is being started, it creates some flag, for example, an empty file, or
> something similar, in the root file system; once the check is finished
> properly, the flag is released. I believe that there will be some better
> solutions, which doesn't need additional files, to implement the said
> feature. By adding this feature, the rc script will be able to detect
> whether the last panic is caused by a background fsck, and optionally, have
> fsck -y executed. I think this might be useful.
> 
> Your in-depth observations will be helpful for the project. Thanks in
> advance!
> 
> Cheers,
> -delphij
> 
> > -----Original Message-----
> > From: Q [mailto:q_dolan@yahoo.com.au]
> > Sent: Monday, May 12, 2003 12:09 PM
> > To: 李鑫 Xin LI
> > Subject: RE: Regression observations & misc errata
> > 
> > Thanks for that, I will look into it. However, you might have missed my
> > point.
> > 
> > The couple of times I have had fatal filesystem inconsistencies have
> > been after a kernel panic, or ACPI induced ungraceful powerdown, and
> > even then it is so rare I cannot deliberately reproduce the problem.
> > Regardless of this, my point was not that the inconsistency occured, but
> > rather there has been a change in the resultant system behaviour
> > compared to pre 5.x releases. In the past the system would have failed
> > the fsck and dropped back into single user mode allowing for manual
> > intervention, now the system will boot normally and kernel panic the
> > moment the filesystem error is encountered.
> > 
> > The fix is simple enough, but the cause of the panic may not be
> > immediately obvious, or may take several minutes to occur.
> > 
> > Seeya...Q



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