find: bad status-- /u/tu

[Chris Siebenmann]

In article <8310 at xanth.cs.odu.edu> kremer at cs.odu.edu (Lloyd Kremer) writes:
...
| Yes, and after unlinking and linking the relevant directories, and everything
| appears to be correct in the 'ls -id' tests, it would be very wise to unmount
| and 'fsck -y -D' the affected filesystem.  Your repairs may be incomplete,
| or the filesystem may have other problems of which you are not (yet) aware.
| It may avoid some nasty surprises in the future.

 Please *don't* ever use 'fsck -y' in any shape or form; bad things
can happen (people wanting details of how to take it out of /etc/rc
can send me email). Note that you should pay careful attention to
fsck's error messages, and just because your 3B1 boots doesn't mean
you don't have a scrambled directory; there is at least one
circumstance where fsck can detect a problem and give a message, but
not fix it and not exit with any error status. It happened to me, and
here is the story:

[This happened around the beginning of March, just after Jim Joyce had
given a talk here about data recovery from crashed disks. The Ziebmef
is a 3B1.]

 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. 



-- 
"He recognized her; said that he remembered her from when he'd been a
 child; expressed surprise she was still alive; suggested novel ways to 
 remedy that fact..."
Chris Siebenmann		uunet!{utgpu!moore,attcan!telly}!ziebmef!cks
cks at ziebmef.UUCP	     or	.....!utgpu!{,ontmoh!,ncrcan!brambo!}cks