fsck read failure on 10.20

[Carol Schmitt]

I have one vxfs file system on 10.20 that is failing fsck with the following error:

fsck read failure bno = 1552 off = 0 len = 8192.

Would a simple restore from tape cure this problem?

[Patrick Wallek]

I doubt just restoring your files would solve this.

Have you tried doing a 'fsck -o full /dev/vg??/lvol??'?

I suspect that you may have a bad spot on the disk.

[Jeff Schussele]

Hi Carol,

Probably not as it appears that that block (1552) has gone or is going bad.
You need to run fsck -o full to clean up the FS.
Assuming this is a vxfs FS, unmount it & run

fsck -F vxfs -o full /dev/vg_name/rlv_name

Note the need fot the raw LV in the command.

HTH,
Jeff

[Steven E. Protter]

Answer all the fsck questions yes, even if they frighten you, otherwise fsck won't do anything.

Take note of errors for support in case they are serious.

SEP

[Bill Hassell]

fsck can't fix hardware problems. The block is unreadable and cannot be ignored. fsck fixes structural and logical problems with directories and files but cannot do anything with a bad block. The mediainit program will tell the disk's firmware to reformat the disk (fixing any bad blocks) but with a total loss of all data on all tracks.

[Carol Schmitt]

Our system configuration is 12 logical volumes in one volume group, spanning three 16gb disks. I'm not certain which disk is bad, as lvol12 spans two physical disks. How do I determine which disk has the bad block, and therefore which one to run mediainit on?

[Carol Schmitt]

Thanks, so far, for all your quick responses to my dilemma.

I was able to determine which physical disk contained the bad blocks. vg00 contains 12 logical volumes and spans three physical disks. lvol11 and lvol12 are both on the bad disk. lvol12 is the logical volume that I cannot mount because of the bad blocks on the disk. I was able to move the data (pvmove) in lvol11 from the bad disk to an identical, unused disk in the system (lucky for me I had one).

Next, I removed lvol12 from vg00 (used SAM) and built that logical volume on the new disk (again, using SAM). I then attempted to restore from tape, the fs that was mounted on lvol12 to the new disk where lvol12 now exists. But, the files appear to be restoring to the bad disk and not the good disk. I thought I had successfully removed the logical volume from that disk and built it on the new disk, but I must be missing something. Any help with this would be greatly appreciated.

Once I get the data restored properly, I would like to initialize the bad disk (pvcreate or mediainit) so I can have it as a spare.

[Eugeny Brychkov]

Try mediainit as Bill proposed. Then do 'dd if=/dev/rdsk/cXtYdZ of=/dev/null bs=4096k' (put correct device file here) and if it will fail with 'I/O error' message then do not use this disk any more
Eugeny

[Frank Slootweg]

If you remove a LV and then re-add it, then, especially with SAM, it will probably go back to the same place, i.e. the bad disk, hence your problem.

I do not know if SAM can do this (check SAM's options, etc.), but with LVM commands you can prevent this:

First use lvcreate to create the LV with a *zero* size.

Then use lvextend to give it the right size *and* to put it on the desired disk (see "pv_path ..." parameter of lvextend.

*Check* your results with "lvdisplay -v ...". lvdisplay should only mention the desired (/dev/dsk/...) disk(s).

> Once I get the data restored properly, I would
> like to initialize the bad disk (pvcreate or mediainit) > so I can have it as a spare.

Don't do that, just get rid of it, or get it *fixed* (if possible).

[Carol Schmitt]

So you wouldn't recommend doing either a mediainit or a pvcreate on the disk? I would like to see if it's at all salvagable. I've taken it out of the volume group so it is just sitting idle.

[Frank Slootweg · Accepted solution]

No I wouldn't use mediainit. See the following thread as to why:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x410d57bd90a9d611abdb0090277a778c,00.html

[Pete Randall]

I've never tried such a thing, but I would think you could do a pvcreate (though you may have to do a pvremove first). When you do the pvcreate you can tell it where the bad block is - see man pvcreate.

If you have a support contract, it would be simpler to just replace the disk.


Pete

[Carol Schmitt]

Thank you for your replies. I guess I'm convinced to simply discontinue using this disk.