Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-dillo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!ut-sally!ut-ngp!ut-dillo!darin
From: darin@ut-dillo.UUCP (Darin Adler)
Newsgroups: net.micro.mac
Subject: Re: HD20 error handling at boot
Message-ID: <269@ut-dillo.UUCP>
Date: Tue, 28-Jan-86 00:37:27 EST
Article-I.D.: ut-dillo.269
Posted: Tue Jan 28 00:37:27 1986
Date-Received: Thu, 30-Jan-86 04:38:55 EST
References: <3152@sdcc3.UUCP>
Organization: UTexas Computation Center, Austin, Texas
Lines: 25

<

> Can anyone explain what the HD20 does upon boot after a crash?  Depending
> upon the situation before "the bomb" it will take 2-3 times longer before it
> ejects the floppy.  During that time some intensive hard disk stuff is going
> on.  Everything always turns up fine, but I'm curious what it's doing.  It's
> particularly bad recovering from Switcher with 2-3 applications.  (Gee, I
> wonder why? :-) )

As explained to me at the developer's conference by Scott Knaster:

	The HFS file system maintains a bit map that determines which
	sectors on a disk are free and which are used.  (This in addition to
	a "extents file" that determines where each file is stored.)  When a
	system crash occurs, some sectors may be marked as used, even though
	they are unused, and vice-versa.  When a volume is mounted, if it
	was not properly Unmounted/Flushed the last time it was used, a
	"scavenge" routine runs, determining which sectors are used/unused.

This was nice to hear, because before using HFS, my Corvus volumes would
gradually lose sectors until I had to re-format them.
-- 
Darin Adler	{gatech,harvard,ihnp4,seismo}!ut-sally!ut-dillo!darin

"Such a mass of motion -- do not know where it goes"	P. Gabriel