Unable to mount a file system

[philip lawton]

Hello, I am having trouble mounting a file system on a V11.00 server. The machine has just rebooted and one file system has not mounted. The disk appears to be ok - there are other file systems mounted on it.

I tried to mount it, but was returned
vxfs mount: /dev/vg00/lvol13 is corrupted. needs checking

I tried an fsck, but was returned
vxfs fsck: file system had I/O error(s) on meta-data.
log replay in progress
full file system check required, exiting ...

Any ideas what I should look at? Does the fsck log anywhere? How do I do a full file system check?

Thanks in advance.

[Michael Steele_2]

Regarding "...How do I do a full file system check?..."

# fsck -F vxfs -y -o full /mount_point

Regarding "...Does the fsck log anywhere?..." - No.

Discover the disks associated to /dev/vg00/lvol13 -

# lvdisplay -v /dev/vg00/lvol13 | more

2nd page, physical volumes.

Stat the physical volumes:

ioscan -fnkC disk | more (* STATE = CLAIMED or STATE = NO_HW *)

dd if=/dev/dsk/cXtYd0 of=/dev/null count=1000000

grep -i "oct 04" /var/adm/syslog/syslog.log | grep -i vmunix

dmesg | tail

Paste in any errors

[philip lawton]

Thanks for your help. There was an error in the syslog that I forgot to mention........

Oct 5 02:57:43 sia02_3 vmunix: LVM : Failure in attaching PV (8/8.8.0) to the r
oot volume group.
Oct 5 02:57:43 sia02_3 vmunix: error no : 16

I'll fsck -F now.

Cheers

[philip lawton]

I have ran the fsck -F, which returned......

sia02_3:/ # fsck -F vxfs -y -o full /dev/vg00/lvol13

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 = 235080, off = 0, len = 8192
file system check failure, aborting ...

Am I going to have to newfs?

[Michael Steele_2]

Well, there you go. PV = physical volume. (8/8.8.0) is its HW address. So find the STATE now:

ioscan -fnkH 8/8.8.0

And test the PV with the dd command from above:

dd if=/dev/dsk/cXtYd0 of=/dev/null count=1000000

Count to 5 and . Does the cursor return to the command line? Or does 'dd' become a runaway process. If runaway then the disk is bad. Call HP with info from 'diskinfo' and 'ioscan -fnkH 8/8.8.0'

diskinfo /dev/dsk/cXtYdZ

[philip lawton]

I let the dd command run across the complete disk and it returned........
1000000+0 records in
1000000+0 records out

..........so the hardware looks ok.
Quite an odd one really. I've raised a software call with HP. It will be interesting to find out what is going on.

Thanks for your help.

[Bill Hassell]

An I/O error has occurred which fsck cannot fix. This is especially critial if it is in the filesystem metadata because it isd the roadmap for all the stored files. Since the dd command seems to indicate that the bits on the disk are readable, the likely culprit is that someone decided to reduce the size of the volume. Without a fully patched, Advanced JFS 3.3 using lvreduce will likely destroy the filesystem beyond recovery. What fsck probably encountere was a pointer beyond the end of the (shorter) logical volume. If no one has used the space beyond the shortened lvol, you could try lvextend back to the original size and you may be able to recover.

[Lu Chen]

Hi,

What is the conclusion HP support found? I have same problem now. Thanks.

[Steven E. Protter]

I just had to run fsck on a filesystem and here was the actual command that worked:

fsck -F vxfs -o full -y /dev/vg01/rlvol2

That last part is critical to it actually working.

If its still broke, get out your last backup and run newfs -F vxfs /dev/vg01/rlvol12 and then restore the data.

As far as the actual problem, its almost always bad disk or connection disrution. I found that a problem on the disk array resulting in disconnect caused this problem for me in the past. That was recoverable. Every other time it happened there was hardware that needed to be worked on or replaced.

SEP