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

[Andrew C. <cl...@gn...>]

On Thu, Oct 25, 2001 at 10:52:41AM -0500, Don Mulvey wrote:
> >Actually, it occured to me that it might be easier with 1.5.x, because
> >PedDevice has been abstracted out somewhat (so, it now supports Hurd
> >stores and linux block devices with a single interface), which means we
> >could make an EVMS port of PedDevice, which would take storage objects
> >or logical disks (right?), and provide a PedDevice.
> 
> >Then, we need to re-export partitions, etc. back to EVMS.
> 
> Sure an evms segment plugin could wrapper the PedDevice abstract.

s/PedDevice/PedDisk/ ?
PedDevice == block devices
PedDisk == partition tables

> Mostly,
> you deal with operations on evms segment storage objects. However, on two
> occasions you deal with evms disk storage objects.  First, during the
> discovery phase you are handed a list of disk storage objects (each a
> PedDisk with a null part_list) and are expected to walk the list and create
> segment storage objects that consume the disk object ( add PedPartitions to
> the part_list ).

Trivial ;)  I was looking at the OS2 seg manager for how to do this ;)

> These segment storage objects are of 3 types: metadata,
> data, freespace and should completely map the disk.

Which is exactly the same abstraction libparted uses ;)

> Secondly, a segment
> plugin can be assigned to a disk storage object. In this case, the plugin
> is expected to prepare the disk for its own use.  Currently, I create a
> metadata storage object to represent the mbr track and a freespace object
> to expose the free disk space.

The 1.5.x libparted approach is PedDisks can be created "from disk" (i.e.
via "discovery"), or "from memory", so this should map well :)
OTOH, 1.4.x writes straight to disk with ped_disk_create().

Well, in theory, in 2 weeks, I'll have heaps of time to clean/stabilize
1.5.x...

> I shrink the original freespace partition and change its starting lba so as
> to preserve the original storage object reference, and then create a new
> freespace storage object to expose the gap in front of the new partition.
> If the new data partition consumes the remainder of the freespace
> (freespace segment size==0) then the original freespace partition is
> deleted. User interfaces are suppose to expect changes in the segment list
> whenever "stuff" happens and should reload references.  But I try to help
> them by preserving freespace segment names as best I can.

I tried doing this, but it ended up getting too messy for my taste.
There were lots of special cases to deal with.

> The evms segment plugin is suppose to respond
> to the commit command by writing its partition scheme to the disk ... and
> nothing more ... that is how it contributes to the entire commit procedure.
> Following the segment plugin commits ... feature plugins can commit their
> metadata.  Ah ... a segment manager is but cog in wheel of life ;-)

OK, sounds sane.  So, the solution is to make the "EVMS port" of PedDisk
do nothing but write to disk.

Andrew