Linux OS gyrations to let it know a disk/lun has increased in size

[Alzhy]

We have storage arrays tat support growing a lun/disk that is presented to a host and in active use.

Suppose I have a disk, and it is under device mapper multipath control:

/dev/mapper/EVADSK001

and 8 subpaths (presented on dual HBAs):
/dev/sdaa to /dev/sdah

It was formerly 100GB, I increased its zize to 200GB.

What OS gyrations do I need to do to let the Linux OS know the disk is now 200GB? Just a simple SCSI rescan?

And what about IF the disk is partitioned "wholly"?

i.e. /dev/mapper/EVADSK001p1

Will enlarging the disk automatically make the p1 partition consume un to the end of the new size?


Thanks and TIA!

[Alzhy]

Okay.. I tested it and here's the result.

I increased VDISK size on the EVA.
I then run a SCSI scan.

The disk size now shows the increased size.
Even the lone partition shows as being extended to the end of the new size of the disk.

But here's my issue. My p1 parition is actually an LVM PV of an active LVM VolumeGroup. The PV and the VG still shows the old capacity of the p1 PV. --- Is there something I am missing to twit LVM to tell it - hey the PV has increased!

Anyone?

Normally though the online disk growth faciity will be for disks that will NOT be used as LVM PVs. They will be Oracle ASM member disks. We are hoping that instead of adding disks to an ASM DIskgroup - we can just increase the VDISKS sizes of these disks to keep out VDISK count low so the load on the EVA will be kept low, and ASM stripe width maintained.

[Randy Jones_3 · Accepted solution]

"man pvresize" should get you headed in the right direction.

[Rob Leadbeater]

Hi Alzhy,

My little recipe for doing this is as follows:

Extend the underlying LUN, then rescan at the OS level.

On HP tools with the ProLiant Support Pack installed, then you should be able to use hp_rescan.
Otherwise this works:

# echo "1" > /sys/class/scsi_device//device/rescan

Where LUN path is something like: 0:0:2:0

Resize the Physical Volume that makes up the volume group.:

# pvresize -v /dev/sdc

Resize the logical volume:

# lvresize --size +2G /dev/testVG/robLV


Resize the file system:

On RHEL 5:
# resize2fs /dev/testVG/robLV

One RHEL 4:
# ext2online /dev/testVG/testLV


Hope this helps,

Regards,

Rob

[Alzhy]

Rob, issue is this.

The LVM VG has it's PV on the paritioned EVA disk that was increased. The underlying disk of the PV indeed increased it's size, do did the lone/whole p1 partition but PV size - which was based on original size of disk remained the same.

So wondering I am if there is a pvextend command to tell the PV - hey the EVADSKp001p1 PV now has bigger capacity/extents. To illustrate:

# pvscan
PV /dev/mapper/EVADSK001p1 VG vg_dbraid5 lvm2 [207.99 GB / 0 free]
PV /dev/mapper/EVA7_VM_POOLp1 VG vg_vmpool lvm2 [500.00 GB / 0 free]


# fdisk -l /dev/mapper/EVADSK001

Disk /dev/mapper/EVADSK001: 223.3 GB, 223338299392 bytes
255 heads, 63 sectors/track, 27152 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/mapper/EVADSK001p1 1 27152 218098408+ 83 Linux



So ya see, PV has veen increased...

[Rob Leadbeater]

Hi Alzhy,

Sorry, not seeing what the issue is...

It looks as thought the PV has changed size, so now you just need to use lvresize to change the size of the Logical Volume.

Can you post the output of

# pvdisplay
and
# vgdisplay -v

Cheers,
Rob

[Alzhy]

PVDISPLAY:

# pvdisplay /dev/dm-18
--- Physical volume ---
PV Name /dev/dm-18
VG Name vg_dbraid5
PV Size 207.99 TB / not usable 3.81 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 54524601
Free PE 54471355
Allocated PE 53246
PV UUID CETmR4-rk6h-VUFK-BSHC-6qjI-gaJP-Xtcmpe

/dev/dm-18 is really EVADSK001p1

VGDISPLAY:

# vgdisplay -v vg_dbraid5
Using volume group(s) on command line
Finding volume group "vg_dbraid5"
--- Volume group ---
VG Name vg_dbraid5
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 8
VG Access read/write
VG Status resizable
Clustered yes
Shared no
MAX LV 0
Cur LV 1
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 207.99 TB
PE Size 4.00 MB
Total PE 54524601
Alloc PE / Size 53246 / 207.99 GB
Free PE / Size 54471355 / 207.79 TB
VG UUID IzFt8Y-eIxL-Rhtx-K60g-OGYV-epKa-Tlvtfo

--- Logical volume ---
LV Name /dev/vg_dbraid5/raid5vol
VG Name vg_dbraid5
LV UUID c1Ercd-O81B-Jimz-Xu40-yptL-W9hO-uTELf9
LV Write Access read/write
LV Status available
# open 0
LV Size 207.99 GB
Current LE 53246
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:23

--- Physical volumes ---
PV Name /dev/dm-18
PV UUID CETmR4-rk6h-VUFK-BSHC-6qjI-gaJP-Xtcmpe
PV Status allocatable
Total PE / Free PE 54524601 / 54471355


I tried pvresize on the p1 device as well as /dev/dm-18 but it did not take on the new size of the parition/PV.

[Rob Leadbeater]

The pvdisplay output is interesting...

> PV Size 207.99 TB

Have you really managed to create a Physical Volume of 200+ TeraBytes ??!

I suspect many LVM utilities, fdisk etc. will have difficulty dealing with anything bigger than 2TB.

Cheers,

Rob

[Alzhy]

Yes. Our Storage Arrays are in the order of 1000 Petabytes! ;^))

Kidding of course. Must be a Linux bug...

BUT issue here is pvresize does not work -- either on the mappe, mpath or dm-nn device.

[Rob Leadbeater]

Hi,

You haven't said what version of Linux you're using, however RHEL 5.1 and later has a maximum ext3 file system size of 16TB. Whatever is causing the system to think it has a 200TB disk will be the root issue...

Cheers,

Rob