Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!alberta!auvax!rwa
From: rwa@auvax.UUCP (Ross Alexander)
Newsgroups: comp.sys.mac
Subject: Re: HFS Flames
Message-ID: <465@auvax.UUCP>
Date: 22 Dec 87 00:43:18 GMT
References: <3580@husc6.harvard.edu> <7054@apple.UUCP>
Organization: Athabasca U., Alberta, Canada
Lines: 29
Summary: well, there's a little redundancy in 4.[23] filesystems

In article <7054@apple.UUCP>, rpd@apple.UUCP (Rick Daley) writes:
> Unfortunately, I'm no HFS expert and can't really answer your question.
> But, I do know my way around System V (AT&T) and pre 4.2 BSD UNIX file
> systems.  They do not have any sort of directory redundancy.  I've had
> a similar experience with bad disks under UNIX and things get just as
> messy.  BSD 4.2 introduced a new file system and I never learned all of
> the details.  However, if there are multiple copies of directory stuff
> in 4.2, it's news to this UNIX hacker...

The basic redundancy available in 4.[23] BSD filesystems is the
provision of alternate superblocks (there's always one @ 16, others
get scattered around on a not-obvious-to-me basis).  A superblock is
the little thing that tells you how many sectors-per-track,
tracks-per-cyclinder, cylinders-per-cylinder-group, block size, frag
size, user usage limits, and a lot of other horrible (really neat)
stuff.  Having that, and knowing how to relate the cylinder-group
free block-and-frag lists to files reachable by in-use inodes (inodes
which are referenced in the directory tree) plus stuff reachable from
the inodes without benefit of the directories constitutes most of
BSD's smarts, and is about all fsck(8) and his buddies have to go on.
There are certainly no parallel directories or anything like that.  

And now, the obligatory quote from the BSD docs (from tunefs(8)):

    "Remember, you can tune a filesystem, but you can't tunafish."

Ross Alexander,
guy in charge of knowing this sort of stuff @ Athabasca University,
alberta!auvax!rwa