[linux-lvm] Problems resizing physical volume

[linux-lvm] Problems resizing physical volume

[Avi Kivity]

(resending, first try didn't seem to make it to the archives)

Due to dracut creating huge initrds, I now need a larger /boot.  So I'd 
like to reduce my lvm physical volume on the same disk in order to make 
room.

However, lvm doesn't want me to:

> lvm> pvs
>   PV         VG   Fmt  Attr PSize   PFree
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G

Seems I have enough room.

> lvm> pvresize --setphysicalvolumesize 148.54G /dev/sda2
>   /dev/sda2: cannot resize to 4753 extents as later ones are allocated.
>   0 physical volume(s) resized / 1 physical volume(s) not resized

So it seems lvm wants me to move the data around instead of doing it by 
itself.  What did I do (besides not reading the manual)?

Let's find a new home for the data:

> [root@violet-regb ~]# pvs --segments
>   PV         VG   Fmt  Attr PSize   PFree  Start SSize
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G     0   480
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G   480   192
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G   672   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G   992   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G  1312   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G  1632  2560
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G  4192   128
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G  4320    64
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G  4384   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 10.00G  4704    62

Looks like all extents are already allocated (that's the 'a', right?). 
But it claims that 10G are free!  And sure, if I create a new volume, 
space is found at extent 4384:

> [root@violet-regb ~]# lvcreate -L 1G -n new vg0
>   Logical volume "new" created
> [root@violet-regb ~]# pvs --segments
>   PV         VG   Fmt  Attr PSize   PFree Start SSize
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G     0   480
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G   480   192
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G   672   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G   992   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  1312   320
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  1632  2560
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  4192   128
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  4320    64
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  4384    32
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  4416   288
>   /dev/sda2  vg0  lvm2 a-   148.94G 9.00G  4704    62

32 extents, 32MB each = 1GB.  Let's move the 62 extents at the end manually:

> [root@violet-regb ~]# lvremove vg0/new
> Do you really want to remove active logical volume new? [y/n]: y
>   Logical volume "new" successfully removed
> [root@violet-regb ~]# pvmove /dev/sda2:4704-4765 /dev/sda2:4384-4445
>   No extents available for allocation

At this point I gave up.  Is there any way to accomplish this?

-- 
error compiling committee.c: too many arguments to function

Re: [linux-lvm] Problems resizing physical volume

[Phillip Susi]

On 4/14/2010 5:42 AM, Avi Kivity wrote:
> (resending, first try didn't seem to make it to the archives)
> 
> Due to dracut creating huge initrds, I now need a larger /boot.  So I'd
> like to reduce my lvm physical volume on the same disk in order to make
> room.

This doesn't directly address your issue, but I'd point out that if
/boot were itself an lv instead of a normal partition, resizing it would
be easy ;)

Personally I just leave /boot on the root lv.

> Looks like all extents are already allocated (that's the 'a', right?).
> But it claims that 10G are free!  And sure, if I create a new volume,
> space is found at extent 4384:

The output is kind of silly in that it shows the free extents too
without any indication that they are free.

>> [root@violet-regb ~]# pvmove /dev/sda2:4704-4765 /dev/sda2:4384-4445
>>   No extents available for allocation
> 
> At this point I gave up.  Is there any way to accomplish this?

pvmove normally is used to move segments off the pv to other pvs in
order to free up that pv for removal.  So it is failing since it can not
find space on other disks, since you limited its search to specific
extents on the same disk.  You need to add --alloc anywhere to stop it
from excluding the current disk from its search.  The need for this is
kind of silly given that you explicitly tell it where to move to, it
should probably be assumed, but isn't.

Re: [linux-lvm] Problems resizing physical volume

[Avi Kivity]

On 04/14/2010 05:47 PM, Phillip Susi wrote:
> On 4/14/2010 5:42 AM, Avi Kivity wrote:
>    
>> (resending, first try didn't seem to make it to the archives)
>>
>> Due to dracut creating huge initrds, I now need a larger /boot.  So I'd
>> like to reduce my lvm physical volume on the same disk in order to make
>> room.
>>      
> This doesn't directly address your issue, but I'd point out that if
> /boot were itself an lv instead of a normal partition, resizing it would
> be easy ;)
>    

I don't think my boot loader supports LVs?

> Personally I just leave /boot on the root lv.
>
>    

I'm triple booting, so I have multiple root volumes.

>> Looks like all extents are already allocated (that's the 'a', right?).
>> But it claims that 10G are free!  And sure, if I create a new volume,
>> space is found at extent 4384:
>>      
> The output is kind of silly in that it shows the free extents too
> without any indication that they are free.
>    

Yes.

>>> [root@violet-regb ~]# pvmove /dev/sda2:4704-4765 /dev/sda2:4384-4445
>>>    No extents available for allocation
>>>        
>> At this point I gave up.  Is there any way to accomplish this?
>>      
> pvmove normally is used to move segments off the pv to other pvs in
> order to free up that pv for removal.  So it is failing since it can not
> find space on other disks, since you limited its search to specific
> extents on the same disk.  You need to add --alloc anywhere to stop it
> from excluding the current disk from its search.  The need for this is
> kind of silly given that you explicitly tell it where to move to, it
> should probably be assumed, but isn't.
>    

I'll try it out.  Thanks.

-- 
error compiling committee.c: too many arguments to function

Re: [linux-lvm] Problems resizing physical volume

[Avi Kivity]

On 04/14/2010 05:59 PM, Avi Kivity wrote:
>
>>>> [root@violet-regb ~]# pvmove /dev/sda2:4704-4765 /dev/sda2:4384-4445
>>>>    No extents available for allocation
>>> At this point I gave up.  Is there any way to accomplish this?
>> pvmove normally is used to move segments off the pv to other pvs in
>> order to free up that pv for removal.  So it is failing since it can not
>> find space on other disks, since you limited its search to specific
>> extents on the same disk.  You need to add --alloc anywhere to stop it
>> from excluding the current disk from its search.  The need for this is
>> kind of silly given that you explicitly tell it where to move to, it
>> should probably be assumed, but isn't.
>
> I'll try it out.  Thanks.
>

It worked, but only after I removed the destination extent specification.

-- 
error compiling committee.c: too many arguments to function

Re: [linux-lvm] Problems resizing physical volume

[Phillip Susi]

On 4/14/2010 10:59 AM, Avi Kivity wrote:
> I don't think my boot loader supports LVs?

grub2 does ;)

Re: [linux-lvm] Problems resizing physical volume

[Stuart D. Gathman]

On Wed, 14 Apr 2010, Phillip Susi wrote:

> This doesn't directly address your issue, but I'd point out that if
> /boot were itself an lv instead of a normal partition, resizing it would
> be easy ;)
> 
> Personally I just leave /boot on the root lv.

Is that with GRUB or LILO?  Last I knew, grub on EL5.4 didn't support
booting from LVM.  I assume LILO would work, since it goes by absolute
sectors.  Which GRUB version supports LVM?

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Problems resizing physical volume

[Phillip Susi]

On 4/14/2010 4:05 PM, Stuart D. Gathman wrote:
> Is that with GRUB or LILO?  Last I knew, grub on EL5.4 didn't support
> booting from LVM.  I assume LILO would work, since it goes by absolute
> sectors.  Which GRUB version supports LVM?

Grub2.  I think it even understands striped volumes.  It does not
understand snapshots yet.

Re: [linux-lvm] Problems resizing physical volume

[Alasdair G Kergon]

On Wed, Apr 14, 2010 at 05:12:31PM -0400, Phillip Susi wrote:
> Grub2.  

Dangerous code which can mis-process configurations it does not recognise.
I advise people not to use it unless they've tested their specific metadata
gets processed by it correctly.

Alasdair

Re: [linux-lvm] Problems resizing physical volume

[Stuart D. Gathman]

On Wed, 14 Apr 2010, Alasdair G Kergon wrote:

> On Wed, Apr 14, 2010 at 05:12:31PM -0400, Phillip Susi wrote:
> > Grub2.  
> 
> Dangerous code which can mis-process configurations it does not recognise.
> I advise people not to use it unless they've tested their specific metadata
> gets processed by it correctly.

AIX had a clever way of integrating their LVM with boot.  There was a specially
marked boot LV that was required to have exactly one extent, and was not 
allowed to move (without updating the boot code).  The "boot" flag
caused the userspace tools to prevent operations that might leave the
system unbootable.

This reduces LVM to the equivalent of a partition as far as the
boot code is concerned.

-- 
	      Stuart D. Gathman <stuart@bmsi.com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [linux-lvm] Problems resizing physical volume

[Alasdair G Kergon]

On Wed, Apr 14, 2010 at 05:57:05PM -0400, Stuart D. Gathman wrote:
> This reduces LVM to the equivalent of a partition as far as the
> boot code is concerned.
 
That's been discussed, but nothing happened.  It's pretty easy to do.

Instead a primitive parser was written for grub2 independently of the
LVM2 developers that can read a subset of LVM2 metadata while being
unaware of its own limitations - so it is straightforward to generate
correct LVM2 metadata that the parser will misinterpret and use to
activate volumes jumbling up your data.  Don't use it without first
testing it processes your specific metadata correctly.

A supportable redesign would see the code that grubN uses provided
by the upstream LVM2 package (in some agreed form - library or
source) so that the grub package itself has no specific LVM2 knowledge,
but imports what it needs through some agreed interface.

If people want to work on this - i.e. liase with the grub and lvm
developers to design and code up a suitable interface - please step
forward and start talking to us!

Alasdair

Re: [linux-lvm] Problems resizing physical volume

[Ron Johnson]

On 04/14/2010 09:47 AM, Phillip Susi wrote:
[snip]
>
> This doesn't directly address your issue, but I'd point out that if
> /boot were itself an lv instead of a normal partition, resizing it would
> be easy ;)
>
> Personally I just leave /boot on the root lv.
>

OTOH, you can never go wrong following the K.I.S.S. principle, 
especially when disks are so large that 30GB is less than 5% of 
capacity.  We use LVs for data directories only.

-- 
Dissent is patriotic, remember?