Operating System - HP-UX
1825720 Members
3328 Online
109686 Solutions
New Discussion

Re: VXFS file system - full fsck required

 
hp admin
Frequent Advisor

VXFS file system - full fsck required

Hello;

The "usr" partition becomes corrupted, and when I try to fscked it, I have the message: the full fsck is required.

Hereafter my somes tentative to resolve the propblem; if you have any other ideas:

# fsck -F vxfs -o full /dev/vg00/lvol7
vxfs fsck: file system had I/O error(s) on meta-data.
log replay in progress
pass0 - checking structural files
pass1 - checking inode sanity and blocks
vxfs fsck: fsck read failure bno = 267400, off = 0, len = 8192
file system check failure, aborting ...

# dd if=/dev/vg00/rlvol7 of=/dev/null bs=1024k
dd read error: I/O error
261+0 records in
261+0 records out
#

thank's in advance
4 REPLIES 4
Sanjay_6
Honored Contributor

Re: VXFS file system - full fsck required

Hi,

Looks like you have a problem with /usr. Try a restore from the backup which is doubtful since there are executables in /usr that you may need to do the restore.

I think a reinatall of the OS may be the only option.

Are you upto date on the jfs/vxfs patches. Do you know what caused the corruption of /usr. Was it a system crash or something else.

Hope this helps.

Regds
A. Clay Stephenson
Acclaimed Contributor

Re: VXFS file system - full fsck required

At this point, I would try
fsck -F vxfs -o full,nolog /dev/vg00/rlvol7.

I do assume that you have unmounted /usr before doing this.
If it ain't broke, I can fix that.
Vitek Pepas
Valued Contributor

Re: VXFS file system - full fsck required

Have you checked dmesg for hardware errors?
Florian Heigl (new acc)
Honored Contributor

Re: VXFS file system - full fsck required

I got this I/O error yesterday :)


please check Your LV state, and do fsck -o full,nolog /dev/vg00/lvol7 ...

lvdisplay -v /dev/vg00/lvol7 | grep -i stale

In our case /usr was a mirrored lvol, but the mirror of a single PE was marked stale.
The LV itself was in state available/stale, both PVs were available. I was quite confused as BadBlockRelocation
According to HP this can happen, if the LV was mirrored before filling it with content: when the 'original' side can't be read for some reason, and so the mirror stays stale forever.

I had an hint because Ignite couldn't read a library.

In the end, I created a new lvol, mounted it to /mnt/usr and did a find . -depth | cpio -pdm /mnt/usr

After that I extracted the broken library from the patch it came with, put it in the new /usr, edited /etc/fstab and rebooted, happy ever after.

You surely should find *some* IO errors in dmesg or the logtool.

If You do have an Ignite backup and little time, just identify the affected disk, put it disk aside, and restore the system from ignite.
yesterday I stood at the edge. Today I'm one step ahead.