Date: Tue, 15 May 2001 11:56:30 +0930 From: Greg Lehey <grog@lemis.com> To: Terry Lambert <tlambert@primenet.com> Cc: Kirk McKusick <mckusick@mckusick.com>, 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: <20010515115630.H59553@wantadilla.lemis.com> In-Reply-To: <200105142334.QAA05923@usr06.primenet.com>; from tlambert@primenet.com on Mon, May 14, 2001 at 11:34:02PM %2B0000 References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 14 May 2001 at 23:34:02 +0000, Terry Lambert wrote: >>>> Working under the assumption that the only time fsck is likely to fail >>>> in this manner is if there are FS errors which can't be resolved in >>>> the background, and which may result in further FS damage if left >>>> uncorrected, the best option seems to be to take some action which >>>> prevents this damage. >>>> >>>> The best series of actions might be the following: >>>> >>>> 1) Downgrade the FS to readonly mode. >>> >>> 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. > > Rebooting is a good idea, in any case, since you really can't > trust the results of programs run from a bogified FS. This sounds like a Microsoft idea. Isn't that the reason why they want you to reboot if you do something like changing the default router? > So it would not be safe, for example, to fsck it, get it clean, and > then remount it read/write, since the programs you are running now > came from a damaged FS (seriously damaged, if a background fsck > doesn't succeed). I don't know if this can happen. If it can, there should be other ways of solving it. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20010515115630.H59553>