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

[Andrew Clausen]

On Wed, Oct 24, 2001 at 08:04:51AM -0500, Don Mulvey wrote:
> Yes, Ben was asking about partition management code.  File system interface
> modules are high on our priority list as well.  Gotta be able to talk to
> the file systems when expanding and shrinking volumes.

Indeed ;) 

> >BTW: are you more interested in stability, or getting it "nice"?
> >i.e. should I port 1.4.x or 1.5.x to EVMS?  I think it should be easy to
> >port to 1.5.x later.
> 
> Lets talk about it.  Give me a number where I can reach you or give me a
> call .... actually ... a conference call would work out nicely too.

I personally prefer IRC.  What are your normal work hours?

My home phone number is +61 3 9885 6083.

> Just let me know how you'd like to proceed.

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.

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.

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.

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...


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?)

Andrew