Extendfs failed!

[yulianto piyut]

Hi all,

We have a problem when extendfs logical volume.
We have extend my VG with 3 LUN @500GB, existing LV have 1 TB size and we want to extend this LV to 2.5 TB.
# vgextend /dev/vgappsproddb /dev/dsk/c16t3d6 /dev/dsk/c16t3d7 /dev/dsk/c16t4d0
# lvextend -L 2622336 /dev/vgappsproddb/lvdb11i
# umount /data
# extendfs -F vxfs /dev/vgappsproddb/rlvdb11i
vxfs fsck: file system needs checking
vxfs fsck: cannot extend aggregate
vxfs extendfs: Invocation of the fsck program terminated abnormally.
The file system is marked bad. Run full fsck manually.

is it due to the limitation of hp-ux 11.11? version of the disk layout is 4. We have no online JFS installed at server.
In the manual of extendfs, there is an option -s, how to use it?

[Matti_Kurkela]

Yes, it's a HP-UX 11.11 kernel limitation.

You cannot extend to 2.5 TB: the maximum supported by 11.11 (with any supported disk layout level) is 2.0 TB.

http://docs.hp.com/en/5971-2383/5971-2383.pdf

To use the -s option of extendfs, find the block size used by the filesystem and use it to calculate the new size. But the -s option is not normally necessary. (I think it would be a bad practice to have filesystem sizes different from the underlying LV: if the LV is larger than the filesystem, the space betweeen the end of the filesystem and the end of the LV is unusable and wasted.)

Since the extendfs could not run the fsck command, the filesystem may contain errors. Fix them first before attempting to change filesystem size.

umount /data #(if it has been mounted)
fsck -F vxfs -o full /dev/vgappsproddb/rlvdb11i

After the filesystem check has been completed, try to mount the filesystem and verify it's OK and it's size is less than 2 TB. Then unmount it again.

lvreduce -L 2097152 /dev/vgappsproddb/lvdb11i
extendfs -F vxfs /dev/vgappsproddb/rlvdb11i

After these commands, the filesystem should be extended to exactly 2.0 terabytes and the extra 500 GB or so should be allocatable as another LV if you wish to use it.

MK

[yulianto piyut]

are you sure about lvreduce command without backup & restore the data?
i am confuse about it.

[Matti_Kurkela]

Making a backup before changes is always a smart thing to do, *especially* as your extendfs indicated your filesystem may contain errors.

If your original extendfs did not extend the filesystem from its original 1 TB size, reducing the LV from 2.5 TB to 2.0 TB should be safe.

The lvextend command will always add new disk space to the "tail" end of the LV; the lvreduce command will always reduce the LV by cutting off extra extents at the tail end.

A filesystem starts at the beginning of the LV and is "contiguous" as regards to the LV: if you have a 1 TB filesystem on a 2.5 TB LV, you'll know that the filesystem is located on the LV at the first TB, and that the 1.5 TB at the end is completely unused. So it will be safe to cut 0.5 TB off from the unused tail end, to make the new size of the LV exactly 2.0 TB.

The LV can be non-contiguous on the PVs, but the LVM hides that from the filesystem.

MK

[yulianto piyut]

Matti,

I just tried in another server:

# lvreduce -L 40000 /dev/vg00/lvol9
Warning: The Logical Volume has a file system larger than the reduced size.
Reducing the Logical Volume will cause filesystem corruption.
When a logical volume is reduced useful data might get lost;
do you really want the command to proceed (y/n) : y
Logical volume "/dev/vg00/lvol9" has been successfully reduced.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
# extendfs -F vxfs /dev/vg00/rlvol9
vxfs extendfs: V-3-20139: Only expansion allowed.
# mount /apps
vxfs mount: V-3-24706: /dev/vg00/lvol9 no such device or filesystem on it missing one or more devices

is it?

[yulianto piyut]

sorry, this is the old configuration of the system i have tried to make lvreduce

# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 10485760 181288 10224080 2% /
/dev/vg00/lvol1 2097152 454224 1630176 22% /stand
/dev/vg00/lvol8 12582912 7858832 4687792 63% /var
/dev/vg00/lvol7 16777216 2868072 13800520 17% /usr
/dev/vg00/lvol4 8388608 31696 8291704 0% /tmp
/dev/vg00/lvol6 12582912 5228528 7296936 42% /opt
/dev/vg00/lvol5 8388608 315808 8009784 4% /home
/dev/vg00/lvol9 52428800 2798161 46528753 6% /apps
# ls /apps
lost+found patch
# umount /apps
# lvreduce -L 40000 /dev/vg00/lvol9
Warning: The Logical Volume has a file system larger than the reduced size.
Reducing the Logical Volume will cause filesystem corruption.
When a logical volume is reduced useful data might get lost;
do you really want the command to proceed (y/n) : y
Logical volume "/dev/vg00/lvol9" has been successfully reduced.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
# extendfs -F vxfs /dev/vg00/rlvol9
vxfs extendfs: V-3-20139: Only expansion allowed.
# mount /apps
vxfs mount: V-3-24706: /dev/vg00/lvol9 no such device or filesystem on it missing one or more devices

after reduced, new lv size is below:
LV Name /dev/vg00/lvol9
LV Status available/syncd
LV Size (Mbytes) 40000
Current LE 625
Allocated PE 1250
Used PV 2

[Matti_Kurkela · Accepted solution]

If you lvreduce a filesystem to a size that is smaller than the size of the filesystem inside it, of course your filesystem will be damaged.

In the case of your lvol9, the lvreduce command even warned you about it:
----
Warning: The Logical Volume has a file system larger than the reduced size.
Reducing the Logical Volume will cause filesystem corruption.
----

Normally the filesystem is exactly the same size as the LV, unless there is an extension/reduction operation going on.

But I understood your vgappsproddb/lvdb11i was in that special state: the original lvextend had been successful, but the extendfs had failed.

That means the filesystem size on lvdb11i may still be 1 TB, while the LV is 2.5 TB, i.e. the LV is bigger than the filesystem.

If the filesystem size is still 1 TB, it's still safe to reduce the LV to 2.0 TB (because you won't be able to use the space beyond 2.0 TB in a single filesystem anyway).

You can verify the VxFS filesystem size (as a separate entity from the LV size) by running "fstyp -v /dev/vgappsproddb/lvdb11i". The value "f_blocks" lists the number of blocks contained by the filesystem, and the value "f_frsize" indicates the size of each block. Multiply them together and you'll get the total size of the filesystem in bytes. Divide by 1024 to get the size in kilobytes, by 1024^2 to get the size in megabytes, etc.

If (filesystem size) < (LV size), then you can freely reduce the filesystem to the point that (new LV size) == (filesystem size) without any filesystem reduction operations.

However, it would be a good practice to leave the reduced LV slightly larger than the filesystem size, and then extend the filesystem to completely fill the LV. This should minimize the danger of accidentally reducing the LV too much. In the case of your lvdb11i filesystem this is not an issue: if the current filesystem size is 1.0 TB and the LV size changes from 2.5 TB to 2.0 TB, there's plenty of safety margin.

If (filesystem size) > (LV size), you're in trouble and may already have lost/corrupted some data.

And in HP-UX 11.11, if the filesystem size is larger than 2.0 TB, it may be effectively corrupted/unusable because the kernel won't be able to access any data beyond the 2.0 TB point. The filesystem management tools should stop you from exceeding that limit, but depending on your patch level, this protection may not be perfect: don't blindly rely on it.

MK

[yulianto piyut]

Hi Matti,

very very nice information to us, many thanks for all.
We want to make a testing before going to do at production server. The scenario of testing belows:

1. I want to extend existing LV (/dev/vg01/lvol1) with size 512064 Mbytes.
2. add new lun at the vg01 (500 GB)
3. extend lv to 1 TB
4. reduce lv to 700 GB

i'll inform u soon!

[yulianto piyut]

this is it!

# lvextend -L 1024128 /dev/vg01/lvol1
Logical volume "/dev/vg01/lvol1" has been successfully extended.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
# lvreduce -L 921600 /dev/vg01/lvol1
When a logical volume is reduced useful data might get lost;
do you really want the command to proceed (y/n) : y
Logical volume "/dev/vg01/lvol1" has been successfully reduced.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
# extendfs -F vxfs /dev/vg01/rlvol1
# mount /dev/vg01/lvol1 /var/opt/ignite/recovery/archives
# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 10485760 437320 9969984 4% /
/dev/vg00/lvol1 1776056 50128 1548320 3% /stand
/dev/vg00/lvol8 12582912 2390376 10113016 19% /var
/dev/vg00/lvol7 12582912 2227368 10274752 18% /usr
/dev/vg00/lvol6 4194304 227816 3935568 5% /tmp
/dev/vg00/lvol5 10485760 4463968 5974816 43% /opt
/dev/vg00/lvol10 40894464 6926978 31844525 18% /old_archives
/dev/vg00/lvol4 10485760 21224 10382784 0% /home
/dev/vg00/lvol9 20971520 71784 19593510 0% /apps
DevFS 3 3 0 100% /dev/deviceFileSystem
/dev/vg01/lvol1 943718400 496926492 418867515 54% /var/opt/ignite/recovery/archives