reliable file systems (formerly obscurity)

Geoff Kuenning geoff at desint.UUCP
Mon Mar 17 17:42:02 AEST 1986


In article <346 at hropus.UUCP> ka at hropus.UUCP (Kenneth Almquist) writes:

> > Hate to introduce you to reliable systems, but yes.  A truly robust
> > filesystem isn't bothered by little details like flaky hardware, even if
> > you can't afford to replicate it.		[Geoff Kuenning]
> 
> This is a rather brief introduction; perhaps you could expand on it?
> If the disk drive doesn't write correctly, you've lost the information
> written unless you have replicated it; am I right?

To start, I'm guilty of an inexact referent.  By "replicate it" I was
referring to the hardware.  In theory, known ECC methods could be used
to protect and recover information, but in practice software replication
is much more workable.

Also, note that I said the FILESYSTEM isn't bothered by flaky hardware;
a minor hardware scribble is going to destroy at least some user data
unless you really do replicate every single sector.  However, many
applications can tolerate minor data lossages as long as the filesystem
itself is recoverable.  (For example, a transaction processing system I
did on a reliable filesystem used journal files as well as its main
database.  The assumption was that a non-catastrophic hardware failure
would be unlikely to destroy both the database and the journal file.)

As a concrete example of filesystem robustness, imagine a UNIX
filesystem where BUFSIZ is equal to 20 bytes less than the physical
sector size.  Little efficiency would be lost, since data is already
being copied into the buffer cache.  Those 20 bytes could be used to
hold (for example) forward and back pointer to the adjacent sectors in
the file.  Each file could be preceded by an information block giving
such data as the i-node number, the (or a) parent directory's i-node
number, and the file name in the parent directory.  If the i-nodes are
wiped out, the file can be identified from its first block and the list
links can be followed to reconstruct the i-node contents.

BTW, this stuff would make great material for mod.os;  I would have posted
there if I had the moderator's address.
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff



More information about the Comp.unix mailing list