singer@endor.harvard.edu (THINK Technologies) (12/17/87)
This afternoon, a very small part of my hard disk simply dropped out of
existence. This part of the directory structure included my System file,
and some other files that were in my System Folder. When I did a Disk
First Aid, it said "Unable to verify status of disk". Which is what it
always says. When I did a DiskExpress "Examine Volume", DE said "the directory
on this volume is damaged". Which I already knew.
When I ran HD SC Setup (1.5), it sat around for a minute and then told me it
couldn't find any suitable SCSI drives. However, the Finder, and every
other application, had no problems seeing my hard disk.
What's more, I could switch-launch to the hard disk, eject my floppy, and
run everything just fine, even though the System file was conspicuously absent.
So anyway, I erased the disk and did a restore; I had good backups and
didn't lose anything. Things seem to be OK for now.
** Flame On **
My question: why the HELL isn't there any redundancy in the filesystem?
Any self-respecting file system (unix comes to mind) has copies of the
directory stored elsewhere, and can fall back on these copies if necessary.
Apple, in their infinite wisdom, removed file tags, and justified it by
saying "If you can't restored data without file tags, then file tags are
no help." Nonsense! File tags help restore the information, even if the
directory structure gets lost. This would be nice.
So how about a redundant-directory file system? Can someone offer a GOOD
reason? Besides performance? And disk space? Both are valid considerations,
but when faced with the prospect of total data loss, I'd pick a slower
disk with two copies of the directory. And with a SCSI hard disk (as the
standard is quickly becoming) neither speed nor space overhead is a consider-
ation.
** Flame Off **
Sigh.
--Rich
**The opinions stated herein are my own opinions and do not necessarily
represent the policies or opinions of my employer (THINK Technologies).
* Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer *
* Customer Support | singer@endor.harvard.edu *
* Symantec, THINK Technologies Division. (No snappy quote) *rpd@apple.UUCP (Rick Daley) (12/18/87)
In article <3580@husc6.harvard.edu>, singer@endor.harvard.edu (THINK Technologies) writes: > My question: why the HELL isn't there any redundancy in the filesystem? > Any self-respecting file system (unix comes to mind) has copies of the > directory stored elsewhere, and can fall back on these copies if necessary. 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... Rick Daley rpd@apple.uucp
olson@endor.harvard.edu (Eric K. Olson) (12/18/87)
In a recent article THINK Technologies writes: >Apple, in their infinite wisdom, removed file tags, and justified it by >saying "If you can't restored data without file tags, then file tags are >no help." Nonsense! File tags help restore the information, even if the >directory structure gets lost. This would be nice. File tags might have been useful for scavenging a disk if they had been maintained properly and consistently. In fact, they were of little value and the added complexity of 524 byte sectors on hard disks made them more trouble than they worth. Floppies (MFS for sure and maybe HFS) when they're formatted have two directories, but I believe the file system only updates one of them for speed. How about a compressing, error-correcting file system that can endure disk- level data corruption to a degree? -Eric I am not affiliated. Eric K. Olson olson@endor.harvard.edu harvard!endor!olson D0760 (Name) (ArpaNet) (UseNet) (AppleLink)
ephraim@think.COM (ephraim vishniac) (12/19/87)
In article <3600@husc6.harvard.edu> olson@endor.UUCP (Eric K. Olson) writes: > [discussion about file tags, their merits and costs] > >Floppies (MFS for sure and maybe HFS) when they're formatted have two >directories, but I believe the file system only updates one of them for >speed. When a volume is initialized, a copy of the volume header (sector 2) is placed just short of the end of the volume, in the next-to-last sector. Even this is some use for scavenging, as it retains basic info about the original state of the disk: a name, the volume allocation unit, whether it's MFS or HFS, and perhaps other good things. A small yuk: Apple's sample SCSI driver has a bug that prevents use of the very last sector on a drive. The bug escaped notice because volumes are normally used only through the next-to-last sector (see above). But, the bug serves as a signature to help you see if your disk vendor mindlessly copied Apple's sample code, bugs and all. Do this now: take FEdit (or equivalent) and try to read the last sector of your disk... Ephraim Vishniac ephraim@think.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214
singer@endor.harvard.edu (THINK Technologies) (12/19/87)
In article <3600@husc6.harvard.edu> olson@endor.UUCP (Eric K. Olson) writes: >In a recent article THINK Technologies writes: ^^^^^^^^^^^^^^^^^^ I take exception to that attribution. I wrote the article, and my disclaimer explicitly says that the article represents my own opinions and not the opinions of THINK Technologies. >File tags might have been useful for scavenging a disk if they had been >maintained properly and consistently. In fact, they were of little value >and the added complexity of 524 byte sectors on hard disks made them more >trouble than they worth. "Than they are worth"? What if they can save an entire customer data base? Or an accounts receivable database? Or the sources to your latest and greatest product, soon to be released? Are they worth less, or more? >Floppies (MFS for sure and maybe HFS) when they're formatted have two >directories, but I believe the file system only updates one of them for >speed. Hmph. >How about a compressing, error-correcting file system that can endure disk- >level data corruption to a degree? If you're being sarcastic, it's lost on me. --Rich **The opinions stated herein are my own opinions and do not necessarily represent the policies or opinions of my employer (THINK Technologies). * Richard M. Siegel | {decvax, ucbvax, sun}!harvard!endor!singer * * Customer Support | singer@endor.harvard.edu * * Symantec, THINK Technologies Division. (No snappy quote) *
rwa@auvax.UUCP (Ross Alexander) (12/22/87)
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