Date: Mon, 14 May 2001 09:41:06 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Kirk McKusick <mckusick@mckusick.com> Cc: Mikhail Teterin <mi@misha.privatelabs.com>, Kris Kennaway <kris@obsecurity.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org>, fs@FreeBSD.org Subject: Re: [kris@obsecurity.org: Re: cvs commit: src/etc rc] Message-ID: <Pine.NEB.3.96L.1010514093435.70573C-100000@fledge.watson.org> In-Reply-To: <200105132342.QAA21879@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 13 May 2001, Kirk McKusick wrote: > > Can't a foreground fsck be run at this moment? Having to reboot for > > anything is rather ugly... I'm sure there is a reason it can not, I'm > > just wondering, what that reason is. Thanks! > > Indeed, a foreground fsck can be run once the downgrade to read-only > has happened. However, doing so automatically is unlikely to be useful > since nearly every error that would get us to this point will also > cause an `fsck -p' to fail. So, at this point a system administrator > is going to have to intervene to do a manual fsck. Once the downgrade > to read-only has happened, no further filesystem damage can occur, so > there is not a great rush to run the manual fsck. However, if the > affected filesystem is something crucial like /var, the system may not > run at all well until the problem is fixed. We've already discussed this scenario on -arch, but for those that missed the discussion, here's a couple of observations about this scenario that are worth keeping in mind: 1) If soft updates and the disk controller are operating normally, this will never happen: this type of failure of fsck can only happen when the constraints described by soft updates disk write ordering are violated. 2) This suggests that the failure in question is a function of a soft updates failure, or a hardware failure. In such a scenario, it is possible for fsck -p to accept the file system as clean, and allow it to be write-mounted in the current scenario, which would result in a (possibly rapid) kernel failure due to the on-disk file system violating normal UFS/FFS writing contraints (no cycles, etc, etc). I.e., if you've accepted that soft updates is pretty correctly implemented, and that your hardware is moderately correct, this scenario is unlikely to occur, and if it does, you're up a creek anyway. One thing that would be nice to see, feature-wise, is a: BACKGROUND_FSCK="NO" # enable/disable background fscking at boot style of entry in rc.conf, with a default of "YES", but a "NO" forcing a normal fsck -p in the foreground. This can currently be controlled in /etc/fstab, but providing an easy on/off toggle for recovery might be useful. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010514093435.70573C-100000>