CentOS - Apr 2011 - Best way to extend pv partition for LVM

I've replaced disks in a hardware RAID 1 with larger disks and enlarged 
the array. Now I have to find a way to tell LVM about the extra space.
It seems there are two ways:
1. delete partition with fdisk and recreate a larger one. This is 
obviously a bit tricky if you do not want to lose data, I haven't 
investigated further yet.
2. create another partition on the disk, pvcreate another pv and then add 
it to the existing volume group with vgextend
3. a possible third way: increase the partition size. According to Google 
most if not all disk tools want to resize a file system as well and since 
there is no file system they will fail. I'm not sure about the status with 
this for the tools that come with CentOS (fdisk, parted, other?)

No. 2 seems to be the easy way. Any objections?
One I thought of:
What does happen when I use No. 2 and I add new lvs? Can it happen that 
new lvs get "spanned" over both pvs or can I assure that a pv gets
created
using only one of the pvs? (I would prefer the latter, it doesn't matter 
if I use a few MB because of the ineffectiveness of allocation.)

Thanks for recommendations.

Kai

Kai Schaetzl wrote:
> I've replaced disks in a hardware RAID 1 with larger disks and enlarged
> the array. Now I have to find a way to tell LVM about the extra space.
> It seems there are two ways:
> 1. delete partition with fdisk and recreate a larger one. This is 
> obviously a bit tricky if you do not want to lose data, I haven't 
> investigated further yet.
> 2. create another partition on the disk, pvcreate another pv and then add 
> it to the existing volume group with vgextend
> 3. a possible third way: increase the partition size. According to Google 
> most if not all disk tools want to resize a file system as well and since 
> there is no file system they will fail. I'm not sure about the status
with
> this for the tools that come with CentOS (fdisk, parted, other?)
> 
> No. 2 seems to be the easy way. Any objections?
> One I thought of:
> What does happen when I use No. 2 and I add new lvs? Can it happen that 
> new lvs get "spanned" over both pvs or can I assure that a pv
gets created
> using only one of the pvs? (I would prefer the latter, it doesn't
matter
> if I use a few MB because of the ineffectiveness of allocation.)
> 
> Thanks for recommendations.
> 
> Kai
> 
Kai,

I ran into the same circumstances a while back and, after a lot of 
consideration and testing, I chose door #2.  It's the most expedient way 
to do it if you have no other resources available, but it does have some 
inefficiencies involved in it.

You COULD use option #1, but it requires some additional resources and a 
LOT of shuffling.  Specifically:

- add an extra disk to the volume group (pvcreate, vgextend)
- move the extents off of the "old" PVs onto the new PV using pvmove
- drop the PVs from the old disks out of the VG
- delete the PVs from the old disks
- repartitioned the old disks
- created PVs on the old disks
- added the new/old PVs to the VG
- move the extents from the temporary PV to the new/old PVs
- remove the temporary disk from the VG, delete the temporary PV

WAY too much shuffling and moving parts to suit me.  The system never 
has to shut down, but performance can truly go into the dumper while 
pvmove is shuffling bits.

I was originally thinking option #3 would be the "best" (i.e. most 
efficient) way, but on a test system I tried several times to extend the 
partitions to include the extra space and failed miserably.  Like you, I 
got stalled at the point of trying to extend the partitions.  parted 
seems to refuse to do so unless there is a supported filesystem on the 
partition, which does not seem to include LVM.

If anybody has some hints about how to work around parted's reluctance 
to merely extend an arbitrary partition, I'd really like to know!  I 
know I could use fdisk to delete the old partition and recreated it at a 
larger size, but that scares the bejesus out of my timid soul, having 
had power failures during critical operations on more than one occasion.
-- 
Jay Leafey - jay.leafey at mindless.com
Memphis, TN
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5529 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20110402/a8cc7537/attachment.bin>

On Sat, 2011-04-02 at 12:02 -0500, Jay Leafey wrote:
> Kai Schaetzl wrote:
> > I've replaced disks in a hardware RAID 1 with larger disks and
enlarged
> > the array. Now I have to find a way to tell LVM about the extra space.
> > It seems there are two ways:
> > 2. create another partition on the disk, pvcreate another pv and then
add
> > it to the existing volume group with vgextend
> > No. 2 seems to be the easy way. Any objections?
Correct.
> > One I thought of:
> > What does happen when I use No. 2 and I add new lvs? Can it happen
that
> > new lvs get "spanned" over both pvs or can I assure that a
pv gets created
> > using only one of the pvs?
You can specify this [I believe] when you create an LV [which PVs are
eligable].
> I ran into the same circumstances a while back and, after a lot of 
> consideration and testing, I chose door #2.  It's the most expedient
way
> to do it if you have no other resources available, but it does have some 
> inefficiencies involved in it.
+1

And doing so is the entire point of LVM.

On Sat, 2 Apr 2011, Jay Leafey wrote:
> You COULD use option #1, but it requires some additional resources and a
> LOT of shuffling.
Why do you need to shuffle?

fdisk /dev/sda
delete the PV partition
create a new PV partition starting at the same sector but ending at the end of
the now larger disk.
write it out and reboot.  I forget whether the reboot is still necessary, but
I think fdisk will warn you it is if you've got mounted filesystems on that
disk.
pvresize /dev/sda1

Done.

I see no problem with #2 though.

jh