From owner-freebsd-current@FreeBSD.ORG Mon May 12 03:36:57 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6781A37B401 for ; Mon, 12 May 2003 03:36:57 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by mx1.FreeBSD.org (Postfix) with SMTP id EB74143FD7 for ; Mon, 12 May 2003 03:36:56 -0700 (PDT) (envelope-from q_dolan@yahoo.com.au) Received: from q.onthenet.com.au (HELO ?192.168.100.155?) (q?dolan@203.10.89.214 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 12 May 2003 10:36:56 -0000 From: Q To: =?UTF-8?Q?=E6=9D=8E?= =?UTF-8?Q?=E9=91=AB?= Xin LI In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Organization: Message-Id: <1052735884.8033.35.camel@boxster.home.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 May 2003 20:38:05 +1000 Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: RE: Regression observations & misc errata X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 10:36:57 -0000 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