* Gary Palmer <[EMAIL PROTECTED]> [000130 22:55] wrote:
> Tom wrote in message ID
> <[EMAIL PROTECTED]>:
> > On Sun, 30 Jan 2000, Daniel C. Sobral wrote:
> >
> > > > Due to the lack of interest, FreeBSD's LFS has fallen into disrepair
> > > > over the years. With the implementation of softupdates in FreeBSD I
> > > > don't think there is any need for LFS any more.
> > >
> > > Repeat that over and over the next time you wait fsck finish a 40 Gb
> > > filesystem checkup, and see if you manage to convince yourself of that.
> >
> > Actually, one of the goals of the softupdates development is a fsck'less
> > filesystem. I'm not sure how this is to be achieved. Probably a metadata
> > journal, though that is just speculation. All the work on metadata update
> > ordering in softupdates would probably apply very nicely to a journal.
>
> The way I understand it is that SoftUpdates is meant to leave the
> metadata consistant enough that the filesystem can be mounted
> read/write immediately at boot, and then have a background fsck go
> through and remove blocks which are allocated in the bitmaps, but
> aren't really used. The only thing you lose by not running the
> background daemon is space. I don't think anyone's running like this
> today, but that is Kirks plan.
(This is me (hopefully accurately) repeating something that Terry
Lambert brought to my attention, credit where credit is due. The
safe-shutdown is my rambling on about a solution.)
Why logging filesystems don't work:
You generally (with the hardware available in PCs now)
can't tell the difference between:
1) loss of power (ok!)
2) crash where the filesystem datastructures weren't corrupted (ok!)
3) crash where the filesystem datastructures were corrupted (ouch)
4) crash where the disk/bus got scrambled (ouch)
the problems with 3 and 4 really make a logging filesystem a
"shot in the dark" because you never know if "safe" areas on the
disk really are safe because there was a chance for corruption.
How do you know that a bug in some other code didn't trounce on
the filesystem's data and write to a spot that's supposedly
"committed"?
Since you generally can't tell between 1,2,3 and 4 you really ought
to fsck in the background anyway.
Good news: afaik Kirk is working on this capability!
Bad news: people running depending on _only_ logging are kidding themselves.
Mini-fix for this problem:
Providing safe shutdown points for the filesystem, if something
"weird" is found, disable further access to that file/directory or
possibly shutdown the entire filesystem.
Basically instead of panic'ing when invalid structures are read from
disk, just disallow further access to the objects.
patches anyone? :)
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
