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>