cks@ziebmef.mef.org (Chris Siebenmann) (09/06/89)
[Enough people have asked that I'm posting this instead of emailing
it. The next article will have details on how to take the fsck -y out
of your /etc/rc.]
Early this morning (around 4am) the Ziebmef's disk got corrupted,
followed shortly afterwards by the system crashing. When I discovered
this around 8am, I decided to boot of my floppy boot disk and fsck the
HD manually (just as a precaution, after hearing Jim Joyce's talk about
data recovery).
Imagine my shock and horror when a stream of 'DUP/BAD INODE' messages
started streaming across the screen, accompanied by:
DUP/BAD INODE=xxxxx OWNER=xxxx MODE=10644
FILE=<something important>
...
CLEAR?
By answering no instead of yes, I was actually able to salvage most
of the files, and at least see what the other missing ones were (such
things as compress ... bad news for the news unbatcher).
There were also a lot of lost files; in fact, too many lost files to
all fit into lost+found at the same time. Of course, if fsck runs out
of space in lost+found, its default action is to delete the file;
completely the wrong thing to do in most circumstances (including this
one, as many of the lost files turned out to be expired news articles
that could be safely deleted after being looked at).
I managed to recover and clean up most everything by successive cycles
of fsck
mount the HD and poke around inspecting & cleaning up stuff
unmount drive
fsck again
This didn't manage to get everything, though; there were a couple of
directories too scrambled for fsck to deal with that I had to zap with
ncheck and clri. Of course, fsck reported 'success' when these
directories were still scrambled.
If I had simply hit the hardware reboot switch and let the default
3B1 /etc/rc take over (it does a 'fsck -y' when problems are detected)
I would have
a. lost some important unrecoverable files claimed to be scrambled,
b. lost some important executables without knowing about it,
c. had several important lost files deleted because lost+found
was full up with expired news articles,
d. and wound up with a disk with potentially deadly directory
problems that /etc/rc thought was fine.
Instead I was able to recover with remarkably few things gone for
good; most of what I couldn't save I managed to restore off various
forms of backup and master disks.
Before this, I thought there wasn't much a non-guru could do except
'fsck -y'; now I know exactly how wrong I was. Needless to say, the
Ziebmef's /etc/rc no longer has an 'fsck -y' in it; even if I can't do
anything more than the equivalent of an 'fsck -y', I'll at least find
out what my losses are.
--
"You're a prisoner of the dark sky/The propeller blades are still
And the evil eye of the hurricane's/Coming in for the kill"
cks@ziebmef.mef.org uunet!{utgpu!moore,attcan!telly}!ziebmef!cks