Quoting Alasdair G Kergon <agk@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@volumehost.com ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
