fsck problems -----

[Marvin Strong]

boot single user and you should be able to check vg00. since lvol10 is not normally part of a default OS install.

fsck -F vxfs -o full {dev}

might work but doesn't look promising.

you can with lvdisplay determine the appropriate size that the filesystem on lvol10 is supposed to be and try to fix it with fsadm or you might have to newfs that filesystem.

[dictum9]

# fsck -F vxfs -o full -y /dev/vg00/rlvol10
file system is larger than device
vxfs fsck: cannot initialize aggregate
file system check failure, aborting ...



It's an architechtural issue all right. /dev/vg00/lvol10 is /var/opt/ignite and 20GB. It should have had its own volume group, or at least as an lvol in some other VG, not vg00. It didn't appear to be mirrored. I don't know why I lost it as a consequence of loosing the primary disk. Anyway, it appears to be hosed.

I will recreate it and install the latest-n-the greatest version of Ignite.

I don't think I have any backups...

[Bill Hassell]

It looks like someone (root) ran lvreduce on the lvol and nothing else. This destroyed the filesystem because part of the lvol has been removed. fsck can fix logical problems but this is technically a physical problem (missing disk space) so fsck will fail with either the message you saw above or an errno 5 which is an I/O error. The I/I error occurs because the driver tries to read beyond the end of the disk (lvol). If you have any idea how large the lvol was before the crash, you might use lvextend to put the lvol back to it's original size. However, since a crash just occurred, your system may be much more damaged than just this lvol. lvreduce is a sledge hammer and knows nothing about files and directories.

[inventsekar_1]

the -o full option reference from man fsck_vxfs:

-o Specify VxFS file system specific options. These
options can be a combination of the following in a
comma-separated list:

full Perform a full file system check.

nolog Do not perform log replay. This option may
be used if the log area was physically
damaged.

Note: Use fsck -o full,nolog on clean file systems. If
fsck -o full without nolog is run on a clean file
system, it first replays the intent log. Since the
VX_FULLFSCK flag is set, an fsck does not update the
inode and extent maps before performing the full check,
so it reports inconsistencies. Use the -n option to
verify file system inconsistencies.

Because VxFS maintains an intent log, a complete check is generally
not required; the default is to replay the intent log only. If
fsck_vxfs detects file system damage or the log replay operation
detects damage, an indication that a complete check is required is
placed in the super-block. In this case, if the -y option was
specified, the full check will be run after the log replay. If the -y
option was not used, fsck must be run again, with the -o full option
to perform the full structural check.

[dictum9]

Bill Hassell

I don't understand where you got the idea that lvreduce was run. I certainly didn't and couldn't find any reference in the history files.

Nevertheless, the fact of the matter is that the lvol, the /var/opt/ignite partition is corrupt, won't mount, won't fsck and I have to reinstall the thing.

I will install it in a different VG. It appears that I don't have enough disks to create its own VG. (A PV cannot be a part of mroe than 1 VG) So I will have to borrow space in another VG.

I think it got corrupt because it was in VG00.

[Steven E. Protter]

Shalom,

Bill may get the idea from the original error message which says the filesystem is bigger than the logical volume.

lvreduce is one way to cause this.

SEP

[Sp4admin]

Hi etc,

fsck -F vxfs -o full -y /dev/vg00/rlov#

You may have some bad hardware if this doesn't work.

sp,

[dictum9]

Okay... Conceivably, it may have been run via sam.

Anyway, I am going to rebuild the whole /var/opt/ignite partition, and use different disks.

This is an olde K570 so that the disks are old and way beyond their mean failure time.

[A. Clay Stephenson]

I think it got corrupt because it was in VG00.

This makes no sense. All anyone has said is that you shouldn't use vg00 for non-OS stuff not that you can't. vg00 is no more and no less prone to failure than any other volume group.

There are other ways to utterly corrupt a filesystem/LVOL rather than running lvreduce. For example, if you dd'ed to the raw drive you could clobber LVM metadata.

[florin_10]

Recreating the file system on a different vg and restoring data from backups, as explained before, will save time and resolves the issue.
flg