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

[Don Mulvey]

>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. 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 ).  These segment storage objects are of 3 types: metadata,
data, freespace and should completely map the disk. 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.



>One headache is metadata and free-space place-holder partitions used by
>libparted change every time you do operations on it.  (i.e. new pointers,
>etc.)  This is really unavoidable... consider the case of adding a
>partition in the middle of freespace, with free space either side of that
>partition... there is no way of preserving the free space partition,
>because a new free space partition must be added.

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.

>This means EVMS can't refer to free space / metadata place-holder
>partitions via pointers.  OTOH, "normal" ("data" or extended partitions)
>are more persistent, so we can hold pointers to those in EVMS structs.

Yup ... should obtain new references.


>So, wrapping the partition table stuff looks fairly straight-forward
>with 1.5.x.  However, it didn't occur to me that we might want more
>than one PedDevice implementation per "on-disk-instance" of libparted.
>It would be nice to have one libparted, that can be shared by
>parted, evms, and whoever else wants to use it.

>Options:
>(1) LD_LIBRARY_PRELOAD, to replace the _arch_device_* functions.  (See
>the bottom of include/device.h in parted 1.5.x)

>(2) vtables + registration.  (i.e. replace _arch_* with a vtable, and
>evms can pass it's own vtable, for it's own devices)

>I guess (2) is cleaner...

Seems better

>Another issue is the _arch_disk_* stuff (see bottom of include/disk.h in
>1.5.x).  The most interesting part is _arch_disk_commit().  This tells
>the kernel that the partition table has changed.  (in <= 2.2.x, via
>an BLKRRPART ioctl, and >= 2.4.x, the blkpg partition interface)
>Do we want libparted communicating with the kernel directly, or should
>libparted be telling EVMS what to tell the kernel?  (or EVMS should
>know on it's own, without help from libparted?)

We never tell block device drivers to read their partition tables (grok
em).  And ... parted would not ask for the commit. The user interface
(ncurses,cmdline,gui,?) tells the engine it wants to commit changes.  The
engine then walks a commit procedure: first kill sectors, then segments,
and so forth and so on ... concluding with the engine telling the kernel to
run a rediscovery procedure. 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 ;-)

I'll look for you on the evms IRC channel.

Later,

Don