[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Don Mulvey
Subject: Re: [Evms-devel] Porting GNU Parted to EVMS
Date: Fri, 26 Oct 2001 11:09:04 -0500

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

I think the comparison goes "sorta" like this ...

PedDevice == disk storage object

I/O to a disk storage object is through the plugin function table.  I/O to
the PedDevice is via arch_specific routines.

((struct plugin_function_s *)logical_disk->plugin->functions.plugin)
_arch_device_read( ((LinuxSpecific *) ((PedDevice *)dev)->arch_specific)
->fd, a,b,c,d);

The evms runtime code does all the device probing and provides this info to
the engine code via an ioctl call.
There are no seek operations on a disk storage object. You read/write to
the logical sector number.

PedPartition == segment storage object

I/O to a segment object is through the plugin function table.  I/O to a
PedPartition is via PedDisk's PedDiskOps.

((struct plugin_function_s *)disk_seg->plugin->functions.plugin)
((PedDisk *)((PedPartition *)ped_part)->disk)->ops->read

Parted has lots and lots and lots and lots of partition management
functions: get_name, set_name, dup, align, ....
The segment storage object answers to commands like: expand, shrink,
delete, create, ...

PedDisk == dunno ... sorta like a container with partitions, partition
commands and some disk commands for reading labels and such.

Seems kinda like a segment manager plugin because PedDisk instances manage
partitioning schemes.

>> The evms segment plugin is suppose to respond
>> to the commit command by writing its partition scheme to the disk ...
>> nothing more ... that is how it contributes to the entire commit
>> Following the segment plugin commits ... feature plugins can commit
>> 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.

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.

You said you were looking at the os2 seg mgr plugin code.   I'll be looking
at libparted code over the weekend ... esp PedDevice ...  pretty neat stuff
... perhaps I'll understand things a bit better by Monday ... ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]