Date: Thu, 21 Sep 2000 22:08:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com (Terry Lambert), tuinstra@clarkson.edu (Dwight Tuinstra), freebsd-fs@FreeBSD.ORG (freebsd-fs) Subject: Re: Journaling Filesystems in bsd? (LFS, anyone?) Message-ID: <200009212208.PAA18776@usr08.primenet.com> In-Reply-To: <200009212146.OAA10470@implode.root.com> from "David Greenman" at Sep 21, 2000 02:46:10 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> >Soft updates can not get around the full fsck problem. See my other > >posting under the title "Crash recovery", wherein I compare the crash > >recovery mechanisms, with special attention to the soft updates > >problem with abbreviated crash recovery. > > I didn't say it could. What I said is that it didn't need to be run before > system startup occured. The problem is that you could have disk corruption above and beyond that which can occur during normal operation, when there is a failure resulting in a reboot with an unclean FS. This may be a corrupt sector containing metadata (maybe even for the "/" directory or "/kernel", if you were writing a new kernel at the time of the crash), or it may be other corrupt data which became corrupted in a cascade failure that resulted in the crash after one or more corrupted blocks were written to disk. Soft updates simply can't recover from this. If, on the other hand, it were a kernel panic that didn't result in corrupt data being written to disk, then there's no danger of a corrupt sector from a DC failure, and there is no danger of other corrupt data needing fsck'ing, so you would be in the situation where the only thing that would be out of date is the cylinder group bitmaps; you could clean this in the background by "locking" access on a cylinder group by cylinder group basis for a short period of time, to clear bits in the bitmap that said an unallocated sector was allocated. This might be seen as brief stalls by an especially observant user or program (say someone is doing profiling of code at the time), but could be accomplished in the background. The problem is that you can not know the reason for the crash, until after the recovery. If there were available CMOS, you could write a "power failure" value into it at boot time, and then write a "safe panic" or an "unsafe panic" code into it at crash time (a power failure would leave the "power failure" code there). The only valid background case would be for a "safe panic", if you could really guarantee such a thing. The worst possible failure resulting in a reboot is a hardware failure of the disk; I would really be loathe to try cleaning in the background after a track failure or even a sector failure (sector failures are identical to sector format corruption after a DC failure during a write, FWIW). Look, soft updates are a good thing, but they aren't a panacea for all problems. Let's laude them for what they do right, but not misrepresent them as doing something they can't. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?200009212208.PAA18776>