VxFS file system resize failed -- /db not the root inode of a vxfs file system

[Rick Braman]

I've run into a problem when trying to extend a VxFS file system on my HP-UX B.11.11 K460 Production server using SAM (as pulled from the log):


Performing task "Extend a logical volume.".

Entering Task Manager with task fs_lv_extend.

Performing task "Extend the size of a logical volume.": Logical volume /dev/
vg01/lvol1 is being extended.

Executing the following command: /sbin/lvextend -l 20480 /dev/vg01/lvol1

Command completed with exit status 0.

Exiting Task Manager with task fs_lv_extend.

Performing task "Resize JFS File System": Resizing /db.

Executing the following command: fsadm -F vxfs -b 41943040 /db

Command completed with exit status 32.

The command used to resize a VxFS file system has failed. The stderr output
from the command is shown below. vxfs fsadm: /db is not the root inode of
a vxfs file system

Exiting Task Manager with task fs_jfs_resize_fs.

Exiting Task Manager with task LV_EXTEND.


...now I've already performed this exact same procedure on my near identical development system without a problem, so I'm not sure what the hang up is here.

SAM still reports the size of /db as being 30720MB under "File Systems", but reports it as being 40960MB under "Logical Volumes".

Based on this and the SAM logs, it appears that the file system extend did not fail completely, but is now in a partial condition. I tried manually rerunning the failed command "fsadm -F vxfs -b 41943040 /db", but it returned the same error.

Unfortunately this is a production file system, and I will not be able to unmount it until this weekend when I would like to try and fix this issue.

Any thoughts?

[Geoff Wild]

Do you have onlineJFS? if yes, try:

fsadm -F vxfs -b 41943040 /db

Rgds...Geoff

[Rick Braman]

Hi Geoff,

That's the command that's failing on me. Any explanation as to why?

[Sandman!]

If /db is a mount point then this error indicates possible corruption of the disk-based inodes. umount(1M) the filesystem; fsck it; mount(1M) on /db; and resize.

~hope it helps

[Geoff Wild]

Ah, sorry, missed that in your post.

If you do try the umounting, I would first reduce the lvol back to the original size.

Also, is your Online JFS working correctly?

vxlicense -p

You can try re-enabling it:

/sbin/fs/vxfs/vxenablef -e online


Rgds...Geoff

[Steven E. Protter]

Shalom,

Geoff's assumption, which is a good one is the Online JFS license file is corrupt.

Thats exactly how mine behaved when the same thing happened to me a while ago.

SEP

[Rick Braman]

Hmmm... maybe you guys can give me a little background info on the significance of the Online JFS in this situation.

I don't have a license for Online JFS on my development server...

vrts:vxlicense: INFO: No valid license installed

...yet I had no problem extending this exact same file system on my development server just a couple weeks earlier.

I do however have Online JFS installed on my Production server...

vrts:vxlicense: INFO: Feature name: HP_OnlineJFS [50]
vrts:vxlicense: INFO: Number of licenses: 1 (non-floating)
vrts:vxlicense: INFO: Expiration date: Sun Jun 24 03:00:00 2007 (137.4 days from now)
vrts:vxlicense: INFO: Release Level: 22
vrts:vxlicense: INFO: Machine Class: All
vrts:vxlicense: INFO: Site ID: 0

...but that doesn't appear to be having any problems.

As far as reducing the lvol back to its original size... is that going to corrupt the data currently residing on it? Since a 'bdf' reports that file system as having never changed in size, is it okay to assume that a lvol reduce will be viewed simply as a 'correction' thing by the system and not actually do any physical reduction and/or corrupt the existing data?

What would happen if I tried fsck'ing the file system without reducing the lvol back to its original size?

Thanks,

Rick

[MHudec]

What is the filesystem type of /db?

You can use fsadm not with /db but with rlvol, like /dev/vg01/rlvol1.

What does lvdisplay -v /dev/vg01/lvol1 say in it's top part before logical extents distribution?

There are things which needs to be considered before doing lvm operations, like free physical extents on pvols in volume group, like allocation and distribution of extents (strict, pvg-strict, distributed), etc.

If filesystem was not extended (you say it was not) then you can reduce lvol to it's original size (logical extents count).

Should you have in future any need to resize filesystem and underlying lvol, always use defragmentation:
fsadm -d -e -D -E /mountpoint
then reduce filesystem via fsadm and then underlying lvol.

Nevertheless fsadm would say no-go to filesystem reduction, if there were data living on extents targeted-to-be-reduced. But I usualy run defragmentation before, so I did not see this in real life.

One more piece of advice - use command line for performing lvm operations, you have more control over it than SAM can offer possibly.

[Rick Braman]

Hi Martin,

/db is a VxFS file system.

lvdisplay -v /dev/vg01/lvol1 gives me...

--- Logical volumes ---
LV Name /dev/vg01/lvol1
VG Name /dev/vg01
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 40960
Current LE 20480
Allocated PE 40960
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation PVG-strict/distributed
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c1t3d0 3840 3840
/dev/dsk/c0t2d0 3840 3840
/dev/dsk/c1t1d0 6400 6400
/dev/dsk/c0t0d0 6400 6400
/dev/dsk/c3t3d0 3840 3840
/dev/dsk/c2t2d0 3840 3840
/dev/dsk/c3t1d0 6400 6400
/dev/dsk/c2t0d0 6400 6400

However, a 'bdf' is still showing the original size of this file system before any LV size increase was performed...

/dev/vg01/lvol1 31457280 29940844 1492780 95% /db

If the current data size doesn't increase past the original LV size (30GB), is there anything stopping new data growth from being written to the newly added 10GB extent?

[MHudec]

Nope. You just extended lvol to 40G, but this did not happen to filesystem living there, which is still on 30G, as bdf shows. So those 10G are present only on LVM level, and not on filesystem level.

[Rick Braman]

Okay then,

Just to recap what I should try to resolve this problem...

1) umount /db
2) lvreduce -L /dev/vg01/lvol1 (back to original size of 31457280kb)*
3) fsck -F vxfs -o full /dev/vg01/rlvol1
4) lvextend -l 20480 /dev/vg01/lvol1
5) fsadm -F vxfs -b 41943040 /db
6) mount /db

*If the original size was only known in kb (31457280kb in this case) would the "" be 31457280 (kb) or 31457 (mb)? But since it is being mirrored, should that number really be either 62914560 (kb) or 62915 (mb)?

For some reason I'm thinking it should be 61440, since I believe the /db file system was probably 30720 before the lvextend problem based on what I'm seeing in the lvdisplay.

[Robert-Jan Goossens]

Hi,

--
1) umount /db
2) lvreduce -L /dev/vg01/lvol1 (back to original size of 31457280kb)*
3) fsck -F vxfs -o full /dev/vg01/rlvol1
4) lvextend -l 20480 /dev/vg01/lvol1
5) fsadm -F vxfs -b 41943040 /db
6) mount /db
--

No need to preform a fsck, you did not corrupt the filesysem.

1) stop the database/application
2) umount /db
3) extendfs /dev/vg01/rlvol1
4) mount /db
5) bdf

Don't worry about mirroring, the MirrorUx software will take of that.

Regards,
Robert-Jan

[Rick Braman]

Hi Robert-Jan,

You actually bring up an interesting point by suggesting the use of "extendfs" instead of "fsadm".

In the past when I would extend file systems on my UNIX servers, I would do everything on the command line, and would use "extendfs". This was the first time I ever remember using SAM to do the LV and FS extends.

Now here's where it gets interesting...

My development server had absolutely no problems when I used SAM to extend the LV and FS. That system does NOT have OnLineJFS installed.

My production server however -- as made very clear here -- has an odd problem when using SAM to extend the FS. This system DOES have OnLineJFS (B3929CA) installed, which I believe is what "fsadm" is directly tied to.

So am I to understand that to resolve this error I am receiving when SAM (or I for that matter) use "fsadm" to extend the FS to match my LV size, is to simply use "extendfs" instead?

That sounds way too easy. ;-)

[James George_1]

Hi

If you don't have online JFS .. Here is the procedure to extend a FS

# Umount /db
# lvextend â L (size in MB) /dev/vg01/lvol1
# Extendfs -F vxfs /dev/vg01/rlvol1
# Mount /dev/vg01/lvdata /db

rgds / james

[James George_1]

Hi

If you don't have online JFS .. Here is the procedure to extend a FS

# Umount /db
# lvextend â L (size in MB) /dev/vg01/lvol1
# Extendfs -F vxfs /dev/vg01/rlvol1
# Mount /dev/vg01/lvol1 /db

rgds / james

[Robert-Jan Goossens]

It is easy :-)

You (sam) did allocate diskspace for this filesystem, you just need to extend the filesystem to match this space. Asof why sam could not preform this task is an other interresting question. You could check if you are up-to-date with sam patches.

In the mean time I would use the commands I gave you to extendfs this filesystem.

I will search the tech database today if I can find a doc matching this case.

Kind regards,
Robert-Jan

[Robert-Jan Goossens]

Hi again,

Ok just a tought. The fsadm -b option requires OnlineJfs, did you install this server from an Ignite image from your prod server?

Robert-Jan

[Rick Braman]

Hi Robert-Jan,

As far as I can remember, OnLineJFS was installed way back when this production server was first set up in 1998. We've never had to restore or recover from an Ignite image. As far as patches go, I updated this system with the latest and greatest of everything in fall of 2006, including patches to SAM, but I don't recall if any patches were applied to OnLineJFS. I don't remember selecting any patches specific to OnLineJFS, so if any were applied, I'd guess that they would have most likely been part of the "Applications Patches for HP-UX 11i v1, June 2006" (GOLDAPPS11i).