bob@rush.howp.com (Bob Ames) (03/29/89)
Anybody seen this:? 3.51# find /u -print [...] /u/tutor /u/tutor/Filecabinet [...] /u/tutor/Filecabinet/Profiles/9600bps:A2 find: bad status-- /u/tutor/Filecabinet/practice/sample6.clf find: bad status-- /u/tutor/Filecabinet/practice/sample5.clf [...] find: bad status-- /u/tutor/Filecabinet/practice/sample1.clf /u/tutor/Wastebasket /u/tutor/Clipboard /u/tutor/.history find: bad status-- /u/hello find: bad status-- /u/dummy find: bad status-- /u/someone [...] 3.51# The bad status messages continue for the rest of the /u directory. The only command which seems to be bothered at all with the /u directory is find. I can cd, ls, od ., anything. All the files are there and intact. The only reason this error was discovered is that the Tape Backup software gave the same errors during the "Checking the file systems" phase of the "Complete Backup". I did an od -cx /u and the output looked somewhat reasonable for a directory. There's plenty of space left on the disk. I tried rebooting. It seems like permissions, but I'm root. This all started after we brought the machine back from ATT for a new power supply |-) Bob Bob Ames The National Organization for the Reform of Marijuana Laws, NORML "Pot is the world's best source of complete protein, alcohol fuel, and paper, is the best fire de-erosion seed, and is america's largest cash crop," USDA bob@rush.cts.com or ncr-sd!rush!bob@nosc.mil or rutgers!ucsd!ncr-sd!rush!bob 619-743-2546 "We each pay a fabulous price for our visions of paradise," Rush
kremer@cs.odu.edu (Lloyd Kremer) (04/01/89)
In article <948@rush.howp.com> bob@rush.howp.com (Bob Ames) writes: >3.51# > /u/tutor/Filecabinet/Profiles/9600bps:A2 > find: bad status-- /u/tutor/Filecabinet/practice/sample6.clf > /u/tutor/.history > find: bad status-- /u/hello > The bad status messages continue for the rest of the /u directory. >This all started after we brought the machine back from ATT for a >new power supply |-) In article <1287@jhunix.HCF.JHU.EDU> ins_anmy@jhunix.HCF.JHU.EDU (Norman Yarvin) writes: >I have exactly the same problem with my filesystem in the neighborhood of > /usr (in places where I have made changes.) "find" seems to be the only >program affected, but I use "find". I'm also using version 3.51 of the >operating system. >Yes, I got a new power supply too. :-? In article <4341@ncrcae.Columbia.NCR.COM> wescott@ncrcae.Columbia.NCR.COM (Mike Wescott) writes: >Try this in /u and some other directories: > ls -id . */.. >Each time you should get the same inode number for each directory. Any >mismatch causes find to take the wrong path in trying to get back to where >it started from. >You can use /etc/link and /etc/unlink to fix. 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. Also, is there some correlation between power supply replacement and filesystem corruption? I sync there might be. :-) Lloyd Kremer {uunet,sun,...}!xanth!kremer
cks@ziebmef.uucp (Chris Siebenmann) (04/04/89)
In article <8310@xanth.cs.odu.edu> kremer@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@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}cks