Re: [Evms-devel] Porting GNU Parted to EVMS

[Don Mulvey]

>> >OK, sounds sane.  So, the solution is to make the "EVMS port" of
PedDisk
>> >do nothing but write to disk.
>>
>> Sounds too simple. PedDisk needs to interact with various user
interfaces,
>> to manage partitioning schemes, found on local and clustered disks,
working
>> within a volume stack where: volume groups(aix,lvm,..) and
>> features(bbr,drivelinking,snapshot,..) may be using the partitions, with
>> the engine orchestrating changes.

>Please elaborate... I don't see how bbr, etc. are relevant.

>Are you thinking of resizing, say?  I would have thought the complexity
>was in the engine...

But of course resizing!  And I very much think that features ... like bbr
... are relevant. When/how do you tell bbr or any feature in a volume stack
... that some underlying storage object was resized and it needs to lay
down metadata in a different location?  You cant just resize the object and
tell the file system to resize ... or the volume will be lost.  So, the
complexity (like you said) does indeed fall within the engine to
orchestrate the resize procedure ... but ... bbr and whomever else is
within the volume stack ... will be: asked by the engine if they can
resize, asked how much they can resize, told when to resize and later still
... when to commit the changes.  Everybody does their part, but the engine
shoulders the responsibility for the resize and plays a much larger role in
the procedure.


Ok Ok ... your right again ... all PedDisk needs to do is to write
partition tables to disk.  The -only- point I was trying to make was that
this is really a simplification of what actually transpires.


There is another evms conference call this coming Friday.  Will you be
dialing in?


Later,

Don