Date: Mon, 14 May 2001 20:27:07 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Greg Lehey <grog@lemis.com> Cc: Kris Kennaway <kris@obsecurity.org>, Terry Lambert <tlambert@primenet.com>, Kirk McKusick <mckusick@mckusick.com>, Mikhail Teterin <mi@misha.privatelabs.com>, 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: <20010514202707.B93481@xor.obsecurity.org> In-Reply-To: <20010515120558.M59553@wantadilla.lemis.com>; from grog@lemis.com on Tue, May 15, 2001 at 12:05:58PM %2B0930 References: <200105132342.QAA21879@beastie.mckusick.com> <200105142334.QAA05923@usr06.primenet.com> <20010515115630.H59553@wantadilla.lemis.com> <20010514193332.A85465@xor.obsecurity.org> <20010515120558.M59553@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--eAbsdosE1cNLO4uF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 15, 2001 at 12:05:58PM +0930, Greg Lehey wrote: > On Monday, 14 May 2001 at 19:33:33 -0700, Kris Kennaway wrote: > > On Tue, May 15, 2001 at 11:56:30AM +0930, Greg Lehey wrote: > > > >>> 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? > > > > No, they're different: one is rebooting to recover from an unknown, > > catastrophic error from which it may be dangerous to continue, and the > > other is rebooting to recover from a non-fatal condition which the > > programmers have not bothered to handle online. >=20 > It's a matter of degree. Since the programmers haven't bothered to > handle it online, it's potentially dangerous to continue without > rebooting. Given enough effort, we could also recover from the failed > fsck. No, we're talking about runtime error recovery in response to an external error versus unimplemented system functionality which can be fixed by making the system more complete. We're not talking about the ability for background fsck to repair different kinds of disk corruption and continue from that point on, we're talking about how to react to corruption of data obtained by running applications _before_ fsck noticed it (and possibly repaired it). I (tautologically) suggest that it's not feasible to cause all possible applications running on FreeBSD to back out reads of corrupted data once it's noticed, and retry from that point. Consider e.g. a file server which may have picked up a corrupted copy of a file due to FS corruption, cached it, and will continue to hand out that corrupted file forever. Background fsck notices the disk corruption and may even be able to repair it, but the file server continues on oblivious. There are other examples one can think of regarding application misbehaviour due to arbitrary filesystem corruption - it's a classic case of "undefined behaviour". Traditionally, applications have been allowed to trust that what they read from the filesystem has already passed fsck, and can therefore be trusted except for runtime kernel bugs which may cause new corruption. Softupdates provides guarantees that most of the time the FS is stable without requiring a fsck (i.e. the traditional guarantee is unchanged), but there are exceptional cases where this is not true, and applications will be started on a corrupted filesystem. These exceptional cases will be detected in the background, at which point in time the system should attempt to recover from the error rather than let the system continue in an undefined state. The only robust way to get applications to back out and reread corrupted data is to restart them all, which is equivalent to a reboot. Kris --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE7AKILWry0BWjoQKURArwHAJwM7Yx31e/WWnwC3kHwjMrskwQs9ACg+EnU dofkC+S8mE7qdYA6xZxEzp8= =m39b -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010514202707.B93481>