Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!bionet!agate!saturn!w-colinp@microsoft.UUCP
From: w-colinp@microsoft.UUCP (Colin Plumb)
Newsgroups: comp.os.research
Subject: Re: OSF and operating system research, and other topics
Message-ID: <5589@saturn.ucsc.edu>
Date: 27 Nov 88 00:08:56 GMT
Sender: usenet@saturn.ucsc.edu
Organization: Microsoft Corp., Redmond WA
Lines: 25
Approved: comp-os-research@jupiter.ucsc.edu


In article <5583@saturn.ucsc.edu> rick@seismo.CSS.GOV (Rick Adams) writes:
>>   * File system meta-data managed with DB techniques: journal,
>>         atomic commit;  fsck should never be necessary again.
>
>It is a truly impressive piece of software that can prevent hardware
>errors from damaging data on the disk. I think I'll keep a copy
>of fsck around anyway.

Not really; the techniques are well known, and involve duplicating all
important information.  There was one file system at Xerox I recall that
was secure against all failures in a single or two consecutive sectors.
(User data could be lost, but the file system's integrity was guaranteed.)
The free block bitmap had no invariants on its correctness; it was merely
a performance-boosting cache.

Essentially the idea is that anything fsck can do, the file system does
automatically.  It's adding "incrementally", i.e. not locking the whole
disk while you fix things up, that's hard.

The people at Xerox also found another benefit: the amount of code that had
to be correct to maintain basic FS consistency was only a few pages.  As
long as the rest worked most of the time, all would be well.
-- 
	-Colin (microsof!w-colinp@sun.com)