ballen@csd4.csd.uwm.edu (Bruce Allen) (07/18/90)
SparcStation 1, 4.0.3: I have gotten an error message from "dump", which is shown below: DUMP: Date of this level 5 dump: Tue Jul 17 20:01:25 1990 DUMP: Date of last level 0 dump: Thu Jun 21 20:25:21 1990 DUMP: Dumping /dev/rsd3h (/home) to /dev/nrst0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: (This should not happen)bread from /dev/rsd3h [block 136768]: count=8192, got=-1 DUMP: corrupted directory, inumber 45100 DUMP: mapping (Pass II) [directories] DUMP: estimated 76582 blocks (37.39MB) on 0.26 tape(s). . . . (dump now continues on normally) I have checked the filesystem using fsck, both non-interactively and interactively. fsck reports no errors. How can I find the supposedly corrupted directory, starting from the information given above? How can this problem be corrected or rectified? System is apparently working fine - I have not noticed any problems. (Note: anyone responding should assume that I have a Unix IQ just slightly above brain-dead...)
ballen@csd4.csd.uwm.edu (Bruce Allen) (07/19/90)
>SparcStation 1, 4.0.3 >I have gotten an error message from "dump", which is shown below: > > DUMP: Date of this level 5 dump: Tue Jul 17 20:01:25 1990 > DUMP: Date of last level 0 dump: Thu Jun 21 20:25:21 1990 > DUMP: Dumping /dev/rsd3h (/home) to /dev/nrst0 > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: (This should not happen)bread from /dev/rsd3h > [block 136768]: count=8192, got=-1 > DUMP: corrupted directory, inumber 45100 > DUMP: mapping (Pass II) [directories] > DUMP: estimated 76582 blocks (37.39MB) on 0.26 tape(s). > . > How do I find/fix this problem? My thanks to david@eng.sun.com who sent me the answer to my question. I am posting the solution here, in case others have this problem. dirac% find /home -inum 45100 -print /home/ballen/string/fast dirac% cd /home/ballen/string/fast /home/ballen/string/fast dirac% ls ! frame.0030 grav_waves.0220 main_hist.1400 Framelist frame.0040 grav_waves.0230 main_hist.1600 Runout frame.0050 grav_waves.0240 main_hist.1800 analyze/ frame.0060 grav_waves.0250 main_hist.2000 ... + lots of other files The problem seemed to be the file called "!". When this was removed, dump was happy again. Thanks, Bruce Allen
das@harvard.harvard.edu (David Steffens) (07/26/90)
In article <10092@brazos.Rice.edu>, ballen@csd4.csd.uwm.edu (Bruce Allen) writes: > The problem seemed to be the file called "!". When this was > removed, dump was happy again. It can't be quite that simple. My users are constantly creating files with wacko names :-) and I have never had any trouble dumping them. Just now I made a directory with a file named "!" in it and I was able to dump the filesystem with no problem. >> DUMP: (This should not happen)bread from /dev/rsd3h >> [block 136768]: count=8192, got=-1 >> DUMP: corrupted directory, inumber 45100 Are you _sure_ the filesystem was good? You did run fsck, right? I'm betting that removing "!" sort of "fixed" whatever was wrong with the directory or one of the underlying inodes. If I were you, I'd run fsck again. And I'd try reading all the blocks of /dev/rsd3h using "dd" to see if one of them has gone bad. Finally, I'd verify that block 136768 is a legal block number for /dev/rsd3. {harvard,mit-eddie,think}!eplunix!das David Allan Steffens 243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory (617) 573-3748 (1400-1900h EST) Mass. Eye & Ear Infirmary I'm a firm believer in learning from one's past mistakes... ...but why should it take so many to get a good education?
tech%easby.durham.ac.uk@pucc.princeton.edu (Technician) (07/30/90)
In article <10092@brazos.Rice.edu>, ballen@csd4.csd.uwm.edu (Bruce Allen) writes: > The problem seemed to be the file called "!". When this was > removed, dump was happy again. To which David Steffens ( eplunix!das@harvard.harvard.edu ) replied *It can't be quite that simple. My users are constantly creating files *with wacko names :-) and I have never had any trouble dumping them. Just *now I made a directory with a file named "!" in it and I was able to dump *the filesystem with no problem. My experience is that 'wacko names' do cause problems, never with dump, as David say's, but with restore, once had to restore an entire partition interactively because restore got upset by a whack'd file name, so couldn't make its tree grow. Hence users here get no sympathy (and sometimes the Grim Reaper) for problems associated with using meta characters in file names. Thats under SUN OS 3.4 (still in the dark ages). And a question to finish off, who knows what about Ciprico controllers under 4.1 (thats a RF3500, and 3200 I think ;-), ie are the drivers now standard, if not how hard/easy/impossible to port are they. Thanks in advance. tech@uk.ac.durham.easby (Jim Cottrell - software technician and all round spelling dunce).