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/