LVOL re-sized, System Rebooted before fsadm to resize FS was done !

[Alzhy]

.. and now I cannot do an fsadm to correctly size the filesystem becuase it is notmounted! Anyone experienced this before?

On Solaris. I can do an fsadm to fix filesystem size on a volume even if it is not mounted. fsadm on HP-UX gives me the following options which always expects a /mount_point :


vxfs fsadm: Usage:
fsadm [-F vxfs] [-V] [-b newsize] [-r rawdev] path_of_mountpoint
fsadm [-F vxfs] [-V] [-DEcde] [-vs] [-a days] [-r rawdev] [-l largesize]
[-p passes] [-t time] path_of_mountpoint
fsadm [-F vxfs] [-o largefiles|nolargefiles] path_of_mountpoint|rawdev
fsadm [-F vxfs] -c path_of_mountpoint

[john kingsley]

Try running extendfs.

[A. Clay Stephenson]

You can use fsadm; specify the device node and the potential mount-point or you can simply use extendfs -F vxfs. Man extendfs_vxfs for details.

[Rita C Workman]

Is the vg that this lvol associated with active ?
If it is and this mountpoint is the only thing not up than try the extendfs the guy above suggested...
If the vg is not up, then first activate it and then try to extend the fs using either the extendfs or fsadm..

HTH,
Rita

[Alzhy]

The LVOL is sized: 481280 MB whilst the FS (which is still intact btw as evidenced by fstyp command) is 486336MB..

oravg01 is the VG
dbx001 is the lvol
/oradata/dbx001 is the mountpoint

I have tried:

fsadm -F vxfs -b 481280M -r /dev/oravg01/rdbx001 /oradata/dbx001

vxfs fsadm: /oradata/dbx001 is not the root inode of a vxfs file sytem

fsadm -F vxfs -b 481280M /oradata/dbx001

vxfs fsadm: /oradata/dbx001 is not the root inode of a vxfs file sytem

I think fsadm only works if the FS/LVOL to be resized is mounted.. Unless there are some undocumented options to it???

[A. Clay Stephenson]

Now we get to the root of the problem. You did a bad bad thing and almost certainly corrupted the filesystem. When you are shrinking a filesystem/LVOL you must first reduce the size of the filesystem BEFORE reducing the size of the LVOL. If you are growing the filesystem/LVOL, you extend the LVOL then extend the filesystem.

If you haven't already reused the space freed by the LVOL reduction, immediately reextend the LVOL and you may be ok.

[Steven E. Protter]

if its not mounted:

extendfs -F vxfs /dev/vg01/rlvol10

make the vg and the rlvol realistic.

Then mount it.

SEP

[john kingsley]

Try running:

extendfs /dev/oravg01/rdbx001

Extendfs only works on unmounted filesystems, and must be run on the raw lvol. In fact, if you did not have online JFS on your system, this is how you would have to extend your filesystem.

[Alzhy]

Here's what we found in history. It looks like the operation was properly done (a Filesystem reduction operation):

734 mount|grep dbx001
735 fsadm -F vxfs -b 481280M /fn_cnv_data 736 bdf /fn_cnv_data
737 lvextend -L 481280 /dev/fhd002a0a/fn_cnv_data
738 man lvreduce
739 lvreduce -L 481280 /dev/fhd002a0a/fn_cnv_data
740 vginfo|more

I just cannot understand why there was an lvextend and an lvreduce.. or if the lvextend actually was a success or not.

Anyways, our weekend reboots no longer did not mount this FS.. and doing an fsck yields:

fsck /dev/oravg01/rdbx001
vxfs fsck: file system had I/O error(s) on meta-data.
file system is larger than device
vxfs fsck: cannot initialize aggregate
file system check failure, aborting ...

[john kingsley]

Whenever I have run lvextend, and the new lvol size is smaller than the old lvol size, I get the message
"lvextend: "LogicalExtenttsNumber" is not bigger than current setting."
and the lvol size doesn't change.

When you run lvdisplay on your lvol, does it show the correct size?