Fwd: First try at improving hal's device mapper support

[Alasdair G Kergon]

> >   And when merging various partitions on it together
> >   $ ls -l /sys/block/dm-1
> >   lrwxrwxrwx  1 root root    0 Dec 22 20:30 device0 -> ../../block/sdb/sdb4/
> >   lrwxrwxrwx  1 root root    0 Dec 22 20:30 device1 -> ../../block/sdb/sdb3/
> >   lrwxrwxrwx  1 root root    0 Dec 22 20:30 device2 -> ../../block/sdb/sdb2/
> >   lrwxrwxrwx  1 root root    0 Dec 22 20:30 device3 -> ../../block/sdb/sdb1/

sysfs is not a very good place for this sort of information IMHO.
Trying to map device-mapper structures onto a filesystem gets extremely messy
however you do it: we gave up.
The best approach we came up with involved hard-linked directories:-)

> >   Now for the bad things. As can be seen in the second example, a dm device can
> >   have multiple backing device. 

Or none.
And with all sorts of relationships with them.

'dmsetup deps' shows you the major/minor numbers of all the dependencies.

[dmsetup is simply a command-line wrapper around libdevmapper.so, which in
turn is a wrapper around the device-mapper ioctls.]

> >   After that a mapping from the dm device to
> >   the target device(s) is created (and thus the deviceX symlinks), but that
> >   doesn't generate any events. 

It generates device-mapper events which a userspace daemon (for example) could wait for.
[The device-mapper multipath tools rely on this.]

> I'm not sure we will need much more than a way to determine that
> e.g. /dev/dm-0 

The supported namespace for device-mapper devices is under /dev/mapper.
Exposure of internals like 'dm-0' anywhere is best avoided.

> 1. for crypto we will assume that the name is sesame_crypto_<sesame-
> uuid> and we can match that against the device object with that
> appropriate volume.crypto.sesame.uuid property.

Every device-mapper device can have three unique identifiers when it
is created:
  name - compulsory, but can be changed any time
  uuid - optional, but constant for the life of the device
  device number - constant for the life of the device

The name is what appears under /dev/mapper: meant to be user-friendly.
The uuid is meant for tools to use internally to reference devices.

Any of the three can be used in most of the device-mapper ioctls to 
indicate the device that the command concerns.

LVM2 uses different uuids for different logical volumes, so if you spot
the same uuid on two different occasions you know it's the same data,
even though the device number might be different e.g. after lvchange -an;
lvchange -ay.

sysfs currently names the device internally with a 'dm-' prefix followed by 
its minor number, but nothing should assume this because it'll have to change
when device-mapper multiple-major-number support is ported from 2.4 to 2.6.

> So, I think it would be useful to talk to the device mapper people to
> make dmsetup not create that device node and instead provide an ioctl
> and make udev create the symbolic links for backwards compatibility.
> With all the nasty asynchronous things that will entail for existing
> users of dmsetup - long live the new asynchronous driver model I
> guess :-)

To avoid race conditions and avoid the system locking up under
low memory, lvm2 has to control exactly when the device 
nodes are created and deleted: it's reading and writing to them
in amongst making its changes, and filesystems could be locked
(like xfs_freeze does), remember.
 
This was designed in the days of devfs, and unfortunately doesn't really
fit into an asynchronous model.

Alasdair
-- 
agk at redhat.com
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal