Message-Id: <199704251242.OAA11939@grendel.sylaba.poznan.pl>
Comments: Authenticated sender is <grendel@[150.254.113.14]>
From: "Mark Habersack" <grendel AT hoth DOT amu DOT edu DOT pl>
Organization: PPP (Pesticide Powered Pumpkins)
To: Pierre Phaneuf <pp AT 55-174 DOT hy DOT cgocable DOT ca>
Date: Fri, 25 Apr 1997 14:41:42 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Usage of directory entries
Reply-to: grendel AT hoth DOT amu DOT edu DOT pl
CC: opendos-developer AT delorie DOT com
References: <199704241124 DOT NAA18259 AT grendel DOT sylaba DOT poznan DOT pl>
In-reply-to: <Pine.LNX.3.95.970424194431.9418C-100000@55-174.hy.cgocable.ca>
Precedence: bulk

Once upon a time (on 24 Apr 97 at 19:47) Pierre Phaneuf said:

> > > Things like file system checking and defragmentation are things better
> > > done while the file system is either unmounted or mounted read-only.
> 
> > Exactly - in such a situation the system is in a known state and thus a
> > possibility to damage anything vital is almost eliminated. But the idea
> > with error detection by the file system code is excellent!
> 
> Yes, something like a simple 16 or 32 bit CRC on each inode... Without
> actually doing any surface checking or "sanity" tests (wrong allocations or
> whatever can go wrong with inode-based fs), you can produce those and check
> them quite quickly... Which would give a warning about the data being
> corrupted and to check the media before any "real" trouble comes up... :-)
Yes CRC with lookup tables may be computed in no time. If only the DMA 
controllers knew how to do it in background ;-))
==================================================
Stand straight, look me in the eye and say goodbye
Stand straight, we drifted past the point of
  reasons why.
Yesterday starts tommorow, tommorow starts today
And the problems seem to be we're picking up the
  pieces of a ricochet...