fsck fails

[gvdb]

We have a volume where fsck fails:

fsck -o full,nolog -y /dev/vg.../lvol...
fsck: /etc/default/fs is used for determining the file system type
vxfs fsck: file system had I/O error(s) on meta-data.
pass0 - checking structural files
pass1 - checking inode sanity and blocks
vxfs fsck: rgetblk bad request, bno = -1029175976, sz = 8192
file system check failure, aborting ...

dd of this volume succeeds without any errors. We did see the following in dmesg:

msgcnt 129 vxfs: mesg 057: vx_esum_bad - /dev/vg.../lvol... file system extent allocation unit summary number 70 marked bad

Is there any way to recover from this?

[Patrick Wallek]

If fsck is failing there is not much that you can do.  You are probably looking at recreating the file system and restoring the data.

[Bill Hassell]

fsck fixes inconsistencies and structural problems with the values in the directories. This can happen when a machine crashes or has a powerfail. However, fsck cannot fix I/O errors. This means that the data cannot be read -- there is a bad area (or several bad areas) on the disk. The disk must be replaced and the data restored.