> The consensus was that: fsck doesn't check for this type of error; format
> should find and fix them if you use format/analyze, loop=yes (~100 times);
> if format doesn't fix it, the drive is about to poop out, ABANDON SHIP.
Actually it's often not quite that bad. You can use the 'repair' command
of format to get rid of the bad blocks. When you get something like
DUMP: (This should not happen)bread from /dev/rsd2g [block 444816]: count=8192, got=-1
dump is referring to (512-byte) block number relative to the start of this
partition. In the syslog, then, you'll get both absolute and relative block
numbers:
Aug 16 14:58:34 helios vmunix: sd2g: Block 492160, Absolute Block: 589360
(I used the numbers from your postings; I would actually expect the block
number from the dump error message and the relative block number from syslog
to be equal.)
Anyway, when you have the absolute block number, you can do
repair <absolute block number>
in format, and that will cure your problems in many cases - because this
particular block is mapped out and never used again. Note that it won't
cure all disk problems (of course).
> Unfortunately, format didn't help me any - it never fixed anything.
> So, I dumped to a new disk I was getting ready to add anyway (I assume
> there will be some bad files there - I just don't know where) and
> will ship the drive back if it's under warranty.
Also, you can find out what filed are affected by using ncheck and
icheck. First
icheck -b <relative block numbers> /dev/rsd2g
to get the inode, then
ncheck -i <inode numbers> /dev/rsd2g
to get the file names.
Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steinar.Haug@runit.sintef.no
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:08 CDT