[linux-lvm] pvresize patch pending

[Zac Slade]

Quoting Alasdair G Kergon <agk at redhat.com>:

> On Fri, Oct 28, 2005 at 09:14:43PM +0100, Zak Kipling wrote:
> > Indeed. I've recently been working on an implementation myself 
> > (primarily because I wanted to grow a live PV on my own system), which 
> > I've attached in its current (somewhat rough, but seemingly working) 
> > state as a patch against CVS HEAD.
>  
> Unless I've missed something while skimming through, I think the code 
> still needs a preceding 'pvcreate --restorefile' equivalent to ensure 
> the size of the device is set correctly in the label (for PVs in a VG).
> (But since the 'Reinstate full PV size when removing from VG.' fix,
> perhaps a code audit would show that we can safely override that label 
> field with the one taken from the VG and allow it to remain wrong on disk.)

I'm going to work on integrating his patch with ours and see if we can't make it
more cohesive. 

>   https://www.redhat.com/archives/linux-lvm/2005-July/msg00033.html
>   https://www.redhat.com/archives/linux-lvm/2005-July/msg00029.html
>   pvs -o +dev_size

I think that to get this part write might take a fundemental shift in the way
pv_write() and _pv_write() behave.  What would be nice is to make pv_write()
distinguish between a pv_create calling it and a pv_resize.  Then have _pv_write
only write the pv mda to the disk.  By doing this _pv_write becomes generic and
allows for further extension.  Also then we can probably implement atomicity for
pv updates (though updating a pv was not initially engineered into lvm it can
become very handy).
 
> Apart from that and the process_each_pv() simplification, it 
> looks pretty good!

Actually there is no need to use process_each_pv().  I don't think that it's
necessary or even wise to support resizing more than one pv at a time.  Instead
it should act less like pvcreate and more like lvextend.  That way supporting
--setphysicalvolumesize makes sense.

> > * Support for metadata formats other than format_text.
> 
> Let's just exclude them with a FMT_RESIZE_PV feature flag.

Well it would be nice to support format_pool I'm not sure what the win for
supporting format1 is....  What would be required architecurally to support
alternative formats?  

> > * Support for more than one mda on a PV (I think it will currently 
> > clobber ones at the end of the PV, since it assumes all space after 
> > pe_start is available for extents).
>  
> Check the number of mdas on the PV and refuse to proceed if it exceeds 1.
> We need to write separate new tools to add/remove/manipulate mdas.

Can't we just borrow the code from pvcreate to manipulate the metadatacopies? 
This shouldn't be the end of the world to get working while the infrastructure
gets put into place to support it more gracefully.

Zac Slade
krakrjak at volumehost.com

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/