Re: pvresize patch pending

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> On Fri, Oct 28, 2005 at 07:37:27PM -0500, Zac Slade wrote:
> > 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).
>   
> I'm reluctant to extend pv_write - long term I want to get rid of it
> (and pv_read also) as PV operations are always awkward and getting in the
> way.
> Everything should be done with (new-style) VGs and LVs.
> 
> pvcreate is also superfluous - I want to absorb it into vgcreate/vgextend
> etc.
> So every labelled volume will always belong to a VG - with enhanced
> vgsplit/vgmerge & allocation facilities.
> CVS now lets you create PVs on LVs - another step towards eliminating
> PVs. 

So instead of using pv_read and pv_write (except for backward compatibility)
this functionality should then be migrated into vgcreate?  Okay, I can see that.
 Doing away with the pv* methods will subtract some abstraction.  However with
this fundamental shift how do you reconcile the pv/vg structures?  Just do away
with the notion of pvs all together or instead have them, but they only exists
as an internal structure not visible to the user?

I'm still learning the codebase and I'm not sure there is an obvious way to
start this.  I'm assuming that you don't want pvcreate reinvented inside
vgcreate, but instead have vgcreate do something new to abstract the underlying
devices by only utilizing a vg structure not having seperate pv structures. 
This code may already exist.  A few hints in the right direction would be nice.
 I'll keep poking around.

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/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux