mount - file system on /dev/vg00/lvol6 has structural damage

[Ken Penland_1]

Has anyone seen this error before?
Anyway to fix it without replacing the drive?

# mount /tmp
mount - file system on /dev/vg00/lvol6 has structural damage

# fsck /dev/vg00/lvol6
vxfs fsck: OLT extent 0 has bad checksum
read of primary OLT failed
vxfs fsck: OLT extent 1 has bad checksum
read of OLT copy failed
vxfs fsck: no valid OLT, cannot continue
file system check failure, aborting ...

[Victor BERRIDGE]

Hi Ken,
>Anyway to fix it without replacing the drive?
How much space to you have left on that pv?
Are you mirrored?
The rapid workaround would be if you have some spare logical extend would be to add a new lv and mount it on /tmp the other alternative would be to use a symbolic link to somewhere with more space then lvremove /dev/vg00/lvol6 and recreate it again

All the best
Victor

[A. Clay Stephenson · Accepted solution]

You are fortunate that this is /tmp. You should be able to simply create a new filesystem.

cat /etc/fstab to make sure that lvol6 is a vxfs filesystem then
newfs -F vxfs /dev/vg00/rlvol6
mount /tmp

Of course, any files residing in /tmp will be lost but that should be of little consequence.

[Alex Lavrov.]

Looks bad. You Object Location Table is damaged, but as I saw it can be fixed sometimes, here is a thread with a document that explains the whole issue:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=317817



And couple of other ones:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=695634
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=13072


Good luck!

[A. Clay Stephenson]

Your situation is not all that uncommon especially if you were using the tmplog or nolog mount options. tmplog is not that bad a choice for /tmp because the files are by definition temporary and there is a performance boost derived from this mount option. The downside is that critical metadata can be lost during a system crash; there is little direct consequence of losing the temporary files but reboots may require intervention that would likely be avoided if the log or delaylog mount options were in effect. It's your call but delaylog is probably a reasonable choice for performance and robustness for /tmp (and /var/tmp if it is a separate filesystem).

[Ken Penland_1]

Thanks to all for your replies..doing a newfs on the file system corrected the problem. You were right, we were lucky this was only /tmp ;)