increasing disk size with OnlineJFS

[Brian Bartley]

Hello,
We have OnlineJFS B.11.11.03.03, and the license is active. I want to perform a simple size increase on one logical volume. We have some unallocated space in /dev/vg00:

View General Information for Volume Group: vg00
Volume Group Name: vg00
Activation Mode: Read/Write
Maximum Capacity (mbytes): 278400
Current Capacity (mbytes): 69440
Megabytes Used: 65256
Megabytes Free: 4184
Max. No. of Logical Volumes: 255
Cur. No. of Logical Volumes: 14
Disk Capacity Limit (mbytes): 17400
Maximum Number of Disks: 16
Current Number of Disks: 4
Hot Spares Configured: 0

I'd like to assign a few hundred extra megabytes to /opt.

I understand that this can be done in SAM with the system running at normal runlevel. Are there any special actions I need to take before or after, or is it just a matter of going into SAM, increase size, and quit? I prefer to use SAM over the command line. Also the /opt lvol is mirrored:

lvdisplay /dev/vg00/lvol4
--- Logical volumes ---
LV Name /dev/vg00/lvol4
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 2148
Current LE 537
Allocated PE 1074
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

What issues are raised by the fact that the lvol I want in increase has a mirror copy? Am I required to make sure the increased space is mirrored as well? Will SAM take care of it automatically? Thanks,

Brian

[James R. Ferguson · Accepted solution]

Hi Brian:

> I understand that this can be done in SAM with the system running at normal runlevel.

That's correct.

> Are there any special actions I need to take before or after, or is it just a matter of going into SAM, increase size, and quit? I prefer to use SAM over the command line. Also the /opt lvol is mirrored:

The usual disclaimer applies. Before you perform LVM changes, you should probably take a backup of the filesystem(s) that are affected. Murphy's law may apply.

> What issues are raised by the fact that the lvol I want in increase has a mirror copy?

Remember that LVM mirroring occurs at the logical volume level and by default, a 'strict' allocation policy is enforced. That means that mirror copies cannot reside on the same physical volume. Therefore, you must have enough free physical extents on separate physical volumes to meet this requirement.

Am I required to make sure the increased space is mirrored as well? Will SAM take care of it automatically?

SAM (calling 'lvextend') will automatically increase (add extents to) all copies.

Regards!

...JRF...

[Brian Bartley]

There isn't enough space on separate disks, the unallocated extents are almost all on the same disk.

I don't think the /opt mount really needs to be mirrored, the contents of /opt usually only change when new software is installed.

Should I break the mirror on the lvol in question? If so, can it be done online with JFS? I see an option in SAM to reduce number of mirror copies, and zero is an option.

Any other suggestions on how to increase size of a logical volume that is mirrored, but there's not enough free extents on separate disks to do the job? Thanks,

Brian

[Torsten.]

>> I don't think the /opt mount really needs to be mirrored.

Why? If the disk fails, your server has a serious problem.

Please post your "vgdisplay -v vg00"!

[James R. Ferguson]

Hi (again) Brian:

> There isn't enough space on separate disks, the unallocated extents are almost all on the same disk.

That's not good. It seems that you have "non-standard" logical volumes and filesystems configured into 'vg00'. This makes operating system upgrades and Ignite cloning cumbersome.

> I don't think the /opt mount really needs to be mirrored, the contents of /opt usually only change when new software is installed.

You're missing an important point. If you lose the unmirrored '/opt' filesystem you will have to recover it from a backup. Mirroring provides you high-availablity and in this case that might be the reboot that brings your server back to a functional state following the crash of one of the disks belonging to vg00. Yes, just having a mirrored boot disk doesn't necessarily mean that a disk hardware failure won't cause a total server crash.

> Should I break the mirror on the lvol in question? If so, can it be done online with JFS? I see an option in SAM to reduce number of mirror copies, and zero is an option.

If you really want to break the mirror for the '/opt' filesystem, use 'lvreduce -m lv_path pv_path' where 'lv_path' might be '/dev/vg00/lvol5' and 'pv_path' is the disk from which you want to remove the mirrors.

You don't need OnlineJFS since these operations are at the logical volume level, not the filesystem level.

> Any other suggestions on how to increase size of a logical volume that is mirrored, but there's not enough free extents on separate disks to do the job?

You don't want to disarm the 'strict' allocation policy, so don't go there. I would urge you to look at moving the non-standard logical volumes to a non-vg00 volume group. This should free physical extents that you need to properly extend and mirror your 'opt' filesystem.

Regards!

...JRF...

[Brian Bartley]

Torsten,

vgdisplay output is below. I guess my logic in thinking that /opt could be de-mirrored is because I was thinking in terms of lost data, for example we have a transaction system that keeps cardholder transactions. I assigned importance to mirroring because if a disk with transactions on it fails we'd still have the transactions on the mirror, whereas if the disk with /opt fails we could restore from tape. However, I now agree with James that it's not worth losing the high availability status of the current /opt mount.

Here's the output of vgdisplay, thanks for all replies. I think I'll look at getting some new disks, we've had this system since Oct 2001.

--- Volume groups ---
VG Name /dev/vg00
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 14
Open LV 14
Max PV 16
Cur PV 4
Act PV 4
Max PE per PV 4350
VGDA 8
PE Size (Mbytes) 4
Total PE 17360
Alloc PE 16314
Free PE 1046
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg00/lvol1
LV Status available/syncd
LV Size (Mbytes) 352
Current LE 88
Allocated PE 176
Used PV 2

LV Name /dev/vg00/lvol2
LV Status available/syncd
LV Size (Mbytes) 2048
Current LE 512
Allocated PE 1024
Used PV 2

LV Name /dev/vg00/lvol3
LV Status available/syncd
LV Size (Mbytes) 412
Current LE 103
Allocated PE 206
Used PV 2

LV Name /dev/vg00/lvol4
LV Status available/syncd
LV Size (Mbytes) 2148
Current LE 537
Allocated PE 1074
Used PV 4

LV Name /dev/vg00/lvol5
LV Status available/syncd
LV Size (Mbytes) 500
Current LE 125
Allocated PE 250
Used PV 2

LV Name /dev/vg00/lvol6
LV Status available/syncd
LV Size (Mbytes) 1800
Current LE 450
Allocated PE 900
Used PV 4

LV Name /dev/vg00/lvol7
LV Status available/syncd
LV Size (Mbytes) 152
Current LE 38
Allocated PE 76
Used PV 2

LV Name /dev/vg00/lvol8
LV Status available/syncd
LV Size (Mbytes) 2548
Current LE 637
Allocated PE 1274
Used PV 2

LV Name /dev/vg00/lvol9
LV Status available/syncd
LV Size (Mbytes) 8120
Current LE 2030
Allocated PE 4060
Used PV 4

LV Name /dev/vg00/lvol10
LV Status available/syncd
LV Size (Mbytes) 11000
Current LE 2750
Allocated PE 5500
Used PV 3

LV Name /dev/vg00/lvol11
LV Status available/syncd
LV Size (Mbytes) 1500
Current LE 375
Allocated PE 750
Used PV 2

LV Name /dev/vg00/lvol9_snap
LV Status available/syncd
LV Size (Mbytes) 1024
Current LE 256
Allocated PE 256
Used PV 1

LV Name /dev/vg00/lvol10_snap
LV Status available/syncd
LV Size (Mbytes) 2252
Current LE 563
Allocated PE 563
Used PV 1

LV Name /dev/vg00/lvol11_snap
LV Status available/syncd
LV Size (Mbytes) 820
Current LE 205
Allocated PE 205
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c1t15d0
PV Status available
Total PE 4340
Free PE 0
Autoswitch On

PV Name /dev/dsk/c5t9d0
PV Status available
Total PE 4340
Free PE 11
Autoswitch On

PV Name /dev/dsk/c3t15d0
PV Status available
Total PE 4340
Free PE 0
Autoswitch On

PV Name /dev/dsk/c5t11d0
PV Status available
Total PE 4340
Free PE 1035
Autoswitch On

[Torsten.]

Sometimes I hope that the system of a questioner doesn't store my data or data related to myself...



However, best to follow the rule to place the OS on vg00, data on other vg's.
You have 3 unmirrored lvols. Is it safe to loose them?

You should really consider to reorganize your system.

[Brian Bartley]

Torsten,
Yes, a reorganization is probably a good idea, but I don't have the skills, it would require a lot of research and calls logged to HP, but I'll look into it.

Also the proprietary application that runs the transaction system is supported by our third-party vendor, they're the ones that did the poor job of disk planning, so I can't make changes to disks without making sure it doesn't break that application, called Blackboard Transact System.

The three non-mirrored disks are for fbackup, a script mounts the volumes for a snapshot during backup, then unmounts them after the backup. Thanks,

Brian

[Torsten.]

If I have a look on this I think it could be an A class with 2 external disks.

In your current configuration you have available space on one disk only, so you cannot extend any mirrored lvol, because you need free space on 2 disks. So a complete reorganization or at least 1 or better 2 new disk may help or better both will help you.

[Steven E. Protter]

Shalom Brian,

NEVER assume sam can or will handle it.

Real sysadmin's don't use or need GUI.

vgdisplay -v
lvdisplay the relevant logical volume
pvdisplay physical volumes.

I generally like to break software mirrors before extending and then rebuild them.

Get the logical volumes extended and mirrored before using Online JFS

Cute OnlineJFS trick.

lvdisplay

Pick the size figure in MB. Put it on clipboard

fsadm -b 2048m

This avoids having to make calculations.

SEP

[Viktor Balogh]

>>Will SAM take care of it automatically?

>NEVER assume sam can or will handle it.

Yepp, Steven has right. At our customer the mirroring is established between separate XP boxes, which stand in different data centers (ca. ~500 meters away from each other, in case of a data center disaster)

In our situation SAM wouldn't handle the extension well, we always mirror manually from the command line. However, there are some machines where the physical volume group "PVG" approach was introduced, and the LV policy was set to "PVG-Strict". There would SAM work flawless, but I prefer the command line anyway.

[Brian Bartley]

Thanks for all the replies, much appreciated.

Brian