RHEL AS4 U4 - Can't grow EVA LUN

[luissma]

I have a RHEL AS4 U4 with LVM and QLogic HBAs attached to an EVA storage. When I extend a LUN I'm able to see new size using SANsurfer but this change is not reflected to O.S. Cannot see new size using fdisk, parted...
Tried 'hp_rescan', 'echo "rescan" >> etc, but it keeps on showing old size.

"blockdev --rereadpt" is not possible just because device is being used (by LVM I guess, because I also umounted F.S.).

Finally I had to reboot system and, after that, create a new partition using fdisk and reread partition table with "partprobe".

Does anyone know if there is a way to do this without rebooting system???

Thanks in advance.

[Steven E. Protter]

Shalom,

You are lucky the system recognized the increase in size after the reboot.

Even fdisk will not recognize a size expansion.

A better approach, if possible is to present a new LUN, set it up anew and copy the data from the old LUN to the new one.

This second approach can avoid reboot.

SEP

[luissma]

Hola Steven,

we were trying to do a LV extension without rebooting system (nor umounting FS). This is why we didn't want to take a new LUN with total size, move data from one FS to the new one and, then, remove original LV.

On the other hand we didn't want to have a two-physical volume LV for administration reasons just because original LUN was only 1 Gb. size and now we have extended it to 2Gb.

So, should I assume that it is not feasible to make available the new size without rebooting and that we've been lucky because it's not usual to see extended size even after rebooting?

Thanks for your response.

[Ivan Ferreira]

The way to go is to add another LUN to the same volume group and extend the logical volume. So, whichever the administrative reasons for what you don't want to have multiple LUNs on a volume group, review them.

[Robert Walker_8]

If you were using LVM (from what you said) you could just add the additional space as a new LVM Physical Volume and then expand the LVM LUN with the added space and then extend the file system. This wouldnt rwquire the downtime or at least not that much as copying etc.

Can you reduce the LUN (reduce via SAN) you have created or probably use fdisk (carefully) and create new partition - this is risky stuff so backups are needed first before anything!!!

[luissma]

Hi all, I knew that the right way to grow a LV/FS is by adding a new LUN and, then, extending VG with a new PV, etc, but I only wanted to know if the LUN extension I proposed could be done without taking the FS off-line.

I assume that it is not possible to do so (and I'll try not to repeat it in the future).

Thanks to all for your support.

[Simon Hargrave]

Why not do the following (assuming you have enough transient space on your array): -

- Publish a new, larger LUN to the host.

- pvcreate that LUN and then vgextend the volume group in question.

- Use pvmove to migrate the logical volumes from the old LUN to the new LUN. Do this ONE LV AT A TIME, since pvmove has been seen to hang when doing an entire volume group at a time!

- vgreduce the old LUN from the volume group.

- Unpublish the old LUN and delete the vdisk.

[luissma]

Finally we left the LV, with the new size, the way we first extended it: Extending LUN in the EVA, rebooting system, creating a new partition using fdisk, rereading partition table with "partprobe" and adding this new partition to the VG as a new PV.

I know this is not the right way to do it but we don't administer SAN storage and administrators didn't want to have a lot of "small" LUNs so they extended the one we had already in use before we could suggest any other method.

Next time, I will ask for a new LUN (whatever the size could be) to be added to the VG/LV or, as Simon suggested, a new LUN with the total amount of space and then, migrate data.


Thanks to all,

Luisma Arranz