Xref: utzoo rec.humor:18942 rec.humor.d:1643 comp.misc:5144
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!decuac!felix!merle
From: merle@felix.UUCP (Linda Merle)
Newsgroups: rec.humor,rec.humor.d,comp.misc
Subject: Re: Looking for Computer Folklore
Keywords: Rebuilding FS from Free Blocks
Message-ID: <83525@felix.UUCP>
Date: 15 Feb 89 00:03:44 GMT
References: <7143@pyr.gatech.EDU> <4744@sfsup.UUCP> <2887@sybase.sybase.com> <1912I78BC@CUNYVM> <1036@tutor.tut.fi> <6761@pogo.GPID.TEK.COM> <557@rpi.edu> <6321@saturn.ucsc.edu>
Sender: daemon@felix.UUCP
Reply-To: merle@felix.UUCP (Linda Merle)
Organization: FileNet Corp., Costa Mesa, CA
Lines: 32

I am reminded of a vendor of mine at a company running Regulus (a real time
Unix that used a variant file system.  Instead of inode lists and lists of
blocks for data (or bit maps, for that matter), it used a single free list for
all blocks, inode and otherwise.). 

One dreary day this fella reported that he'd gotten an fsck error that morning
in block 4 of his file system.  Fsck asked him if he wanted it "fixed".  He
said say, so it did.  It placed everything past the superblock plus one
into the free space list.

"Bummer", said I, "It's restore-time!  You shoulda said 'no' and we could
have tried to fix the damage with our ever-handy fsdb!".

But alas, he had been coding for a week and neglected to make a backup.

He called back a week later, having spent the entire week reassembling his
file system 512 by 512 block by using fsdb to relink the un-zero'ed blocks in
the free space list.  Every 20 or so the block had been re-used to contain
the free space list itself; these he lost, but for the most part, he did it.

Linda Merle




--
======================================================================

"If men are God's gift to women....
 He's really into gag gifts!"

======================================================================