Corrupt logical volume

[Melissa Murphy]

Hello there.

I have two comptuers accessing a RAID tower; each system mounts either a 100GB or 67GB array. I was playing with shutting one down and vgimporting its assigned volume group to the second machine and making sure they could be swapped and still contain all the data. I was asked to simulate a power outage and just unplug one machine without giving it a chance to go through its kill processes, and then try to vgimport its volume groups to the other computer.

This is what I did:

# vgimport vg100 /dev/dsk/c4t2d0
# vgchange -a y vg100
# mount /dev/vg100/lvol1 /export/data
vxfs mount: /dev/vg100/lvol1 is corrupted. needs checking
#

What do I need to do to check this logical volume? Did this happen because I simply pulled the power plug? There is no data in lvol1 right now, but if there were, would it be lost or damaged?

Thank you very much,
Melissa

[Melissa Murphy]

Well, I played around a little more. Wondering if this really helps, or if it is only a temporary fix.

Here is what I did:

# fsck -o full /y /dev/vg100/lvol1
fsck: /etc/default/fs is used for determining the file system type
fsck: /etc/default/fs is used for determining the file system type
vxfs fsck: cannot stat /y
log replay in progress
pass0 - checking structural files
pass1 - checking inode sanity and blocks
pass2 - checking directory linkage
pass3 - checking reference counts
pass4 - checking resource maps
OK to clear log? (ynq)y
set state to CLEAN? (ynq)y
# mount /dev/vg100/lvol1 /export/data

Is it going to be all right, or will I continue to have the problem in the future or anytime I try this again?

Thanks,
Mel

[Melissa Murphy]

And yes, I know that /y is a typo in there. :) I just now realized that. Hm.

Mel

[James R. Ferguson]

Hi Melissa:

Before you mount the filesystems, you need to 'fsck' them for consistency. The problem is that you left your filesystems is an "unknow" state when you powered them off without going through a graceful software shutdown. Internally, structural integrity is suspect. 'fsck' verifies integrity and repairs it.

Since you are working with 'vsfs' filesystems you can do this:

# /sbin/fsck -F vxfs -y -o full /dev/rdsk/cXtYdZ

See the man pages for 'fsck' and for 'fsck_vxfs' for more details.

...JRF...

[Mark Vollmers]

Melissa-

I have heard that it is recommended that you run fsck a few times, as it will not always catch things the first time. other than that, though, I don't know of a whole lot else that you can do to fix a corrupted disk drive. It may have given you that error because UNIX really doesn't like to have the plug pulled on it.

Mark

[Sachin Patel]

Hi Melissa,
It should work fine. We do this very often.
You first do
fsck -F vxfs -y /dev/rdsk/cXtYdZ
Vgimport
Vgchange
Mount

I don?t agree with Mark that you have to run fsck more then once. In our case I never have to run fsck more then once. But if after first fsck it says that file system is not clean then run fsck again.

Sachin

[Peggy Fong]

Hi Melissa

File systems have a flag set that tells whether or not fsck needs to be run. When a file system is unmounted by the system or manually the flage is set to CLEAN. When a system comes down withoug unmounting the file systems (crash, failure, loss of power, etc), then the flag does not get set to CLEAN - it remembers that it was last mounted and did not get unmounted - hence you will always get that message when you do that test.

(This was already mention previously :) )

You do not normally need to use the "full" option when doing fsck, but you do need to use the raw device file for the file system. I noticed the other postees used the disk and not the lvol.

Here is what I normally would use -
fsck -F vxfs -y /dev/vg100/rlvol1

Now, if it cannot be fixed I usually do another fsck (full without using the bitmap log)

fsck -F vxfs -o full,nolog -y /dev/vg100/rlvol1

Just another idea.
Peg

[Manju Kampli]

Hi ,

Since the filesystem type is Vxfs you should not have to woory too much as this has very good recovery procedure.. saying yes to it is very safe

regards,
Manju