Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Nov 2002 15:37:31 -0800
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Brad Knowles <brad.knowles@skynet.be>
Cc:        Kris Kennaway <kris@obsecurity.org>, Robert Watson <rwatson@FreeBSD.ORG>, Mikhail Teterin <mi+mx@aldan.algebra.com>, current@FreeBSD.ORG
Subject:   Re: -current unusable after a crash
Message-ID:  <3DE2B43B.466FEA99@mindspring.com>
References:  <200211250959.39594.mi%2Bmx@aldan.algebra.com> <Pine.NEB.3.96L.1021125102358.33619A-100000@fledge.watson.org> <20021125172445.GA8953@rot13.obsecurity.org> <3DE29DE6.CDD96F3F@mindspring.com> <a05200f1dba0854968c9b@[10.0.1.2]>

next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles wrote:
> At 2:02 PM -0800 2002/11/25, Terry Lambert wrote:
> >  If you made system dumps mandatory (or marked swap with a non-dump
> >  header in case of panic), this still would not handle the "silent
> >  reboot", "double panic", or "single panic with disk I/O trashed"
> >  cases.  8-(.
> 
>         How about we do the safe thing, and only do background fsck if we
> can prove that the system state is something where it would be
> suitable?  Or would that mean that we almost never do background fsck?

It would mean that you can *never* background fsck safely.

The problem is that you need to distinguish a power failure,
which is technically the only safe time to do it, from all
other failure modes.

You can distinguish, at least on R/W FS's, whether or not to
do any fsck (by looking at the "clean" bit), but all other bets
are off.

One approach that works well for desktop systems is to implement
a "soft read-only".  We did this at Artisoft in 1995/1996, when
we ported the VFS stacking framework to Windows 95, and first
implemented a soft updates for FFS/UFS, which we ported to run
on Windows 95 under the stacking framework.

The way a "soft read-only" works is to leave the FS mounted
read/write, and then insert at write attempts, everywhere that
read-only is checked, a check for a "soft read-only" bit on
the in-core superblock.

Basically, we flush out all writeable state to the FS, and then
set the clean bit in the superblock, and flush it to disk, if
I/O on the FS has been idle for a while.

Then, when someone wants to write it, we reset the "dirty" bit,
flush the superblock back out to disk, and, once we know that
the change has been committed to stable storage, we permit the
write operation to continue.


There's actually some problems that now exist in the sync code
in FreeBSD that result in unnecessary writes to the disk, these
days, which make it hard to implement this (the system basically
sync's disk buffers that don't need to be sync'ed, at intervals);
that would have to be fixed before such a system can be used.

The result is a box you can just "turn off", without trashing the
FS, assuming it's relatively quiescent, relative to FS writes
(e.g. desktop systems, as I said at the top).

Similarly, if the system were to panic, lose power, whatever, at
this point, then the FS's would be clean, and come back up with
no need to fsck.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DE2B43B.466FEA99>