Re: EVMS3 and linux block layer architecture, was: alas for thee, ?EVMS

On Tue, 2008-12-02 at 15:39 +0100, Lars Marowsky-Bree wrote:
> On 2008-12-01T12:13:21, Jeremy Jackson <[email protected]> wrote:
> 
> > What type of locking do LVM2 utils use?  Does in-kernel device-mapper
> > provide locking?
> 
> No; device-mapper doesn't provide locking. C-LVM2 syncs via user-space
> and openAIS.

Thinking over the MSDOS partition issue, it came to me that
device-mapper mappings lack traceability... that is to say, the way EVMS
builds a stack of mappings from disk -> msdos segment -> lvm2 container
-> lvm2 lv -> evms volume, once those mappings are setup, and
evms_activate exits, the information used by the discovery process
disappears.  The mappings are somewhat anonymous, for a future run of
EVMS or if say lvm2 tools are run.

In EVMS, there are various plugins that are responsible for different
object types.  Inside evms_activate, the discovery process allows
modules to claim various layers and dm mappings.  I wonder if there is a
way to "mark" the in-kernel dm mappings, similar to how the linux 2.6
BD-claim code does.  If you look in there, you see that the address of
the function claiming a block device ( or a partition thereof ) puts its
address in the struct block_device.  

DM objects are block devices already, so they'd get a struct
block_device already, but the bd-claim only takes the address of a
kernel function, not a userspace label like "MSDOS" or "LVM2"... not far
to got to add that i guess.

To be clear, I see such a label as a way to interoperate between various
components, and possibly provide fine-grained locking.  Perhaps it would
enable interoperability between LVM2, EVMS3, and udev.

It would also help solve user frustration over bd-claim: instead of
"device busy", kernel error message could contain the label, which
should help the user find what is keeping it busy.

As for what to stuff into block_device->bd_holder, it currently is the
address of a kernel function.  I would keep that and perhaps add a label
{ "MSDOS", "LVM2", "MD-RAID", "EVMS" }, and the name of userspace
process and/or library that created the mapping.

> > In pondering what EVMS3 architecture would look like, it occurrs to me
> > that the mismatch between LVM2 and EVMS's use of device-mapper is
> > currently a major impediment to EVMS maintenance... being more like LVM2
> > (or LVM2 being more like EVMS) would give more users/maintainers.
> 
> I don't think the mismatch is at the dm-* level. Both in fact use the
> same dm-* kernel components.

yes, but I was saying it's *how* they use dm that makes them different.
in a simple lvm2 container build of MSDOS partitions, if it has only
compatibility volumes, lvm2 and evms are the same in their use of dm for
the LVM parts, but below the container, the partitions are handled
differently.  I think LVM2 tools would not know how to handle things
after EVMS had set them up that way.  Has anyone tried that?  Time for
me to experiment.

-- 
Jeremy Jackson
Coplanar Networks
(519)489-4903
http://www.coplanar.net
[email protected]


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Evms-devel mailing list
[email protected]
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel