First try at improving hal's device mapper support

[David Zeuthen]

On Fri, 2004-12-31 at 17:16 +0100, Sjoerd Simons wrote:
> On Fri, Dec 31, 2004 at 03:15:46PM +0100, David Zeuthen wrote:
> > On Wed, 2004-12-22 at 21:22 +0100, Sjoerd Simons wrote:
> > 
> > I'm not sure we will need much more than a way to determine that
> > e.g. /dev/dm-0 corresponds to the device_name given by dmsetup/
> > cryptsetup since it is feasible to assume that the tools setting up the
> > device mapper devices can use names encoded in a way that enables hal to
> > infer the backing devices.
> > 
> > 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.
> > 
> > 2. for LVM2 we should have similar volume.lvm2.* properties that include
> > the LVM2 UUID (such a number does exist) and we just decide on a naming
> > scheme to use. In addition we could create hal device objects of
> > capability 'storage' as a fake parent - that will also give us dedicated
> > icon for the drive in e.g. gnome-vfs.
> 
> I would like things to be represented in hal the right way without forcing the 
> user to use certain tools/naming convetions. In my view everything in hal
> should just work without relying on userspace conventions.
> 

It sounds dangerous to me to assume that the mapping the user sets up,
via dmsetup is LVM2, just because the physical volume backing it is the
source. What if the user is creating another mapping? Then we would end
up erroneously adding a hal device object of capability 'volume',
wouldn't that be bad? 

Also, one good reason to rely on the name is a contract: If you use that
kind of name, then you have to make sure that all sources are added to
the mapping (using the suitable LVM2 userspace tools) and you guarantee
to not change the mapping again.

Apart from your general concern about not relying on user space
conventions, do you see any problems with this? I envision we'll just be
shipping callouts (like fstab-sync) to set up all of this and, voila, we
have plug and play of LVM2 arrays. Just works. Do you think this is a
bad idea?

> I don't understand what you mean with fake parents, but it sounds wrong :) 
>   

For what's it worth we also add "fake" hal device objects of capability
'volume' when we discover that there is a disc in your optical drive.
Perhaps fake is the wrong word to use here, my bad. It's just about
sticking the view of hardware that hal exposes.

Anyway - you pretty much have to create a hal device object of
capability storage in order to cover LVM2 volumes; e.g. the hal device
objects of capability 'volume' that we create when we see
e.g. /dev/dm-0. Because, in hal, all volume objects need to reference a
storage object.

Now, for crypto mappings it's sane to use the same storage object as the
source, because, at the end of the day, it's an operation on the source
that is performed (only encrypted). One implication of using the same
storage object is that the UI (gnome-vfs for instance) displays the name
and the icon suitable for the backing storage device. E.g. you get the
USB icon and a sane name. All that jazz. I think that is fine.

For LVM2 mappings, however, there can be multiple sources, e.g. two
different hard drives, and that alone is one reason we cannot use the
same storage object - there is more than one.. In addition, it would
make more sense to make the UI actually display an icon and name that
conveys to the user that this is a logical drive representing a RAID1
set or whatever 

(e.g. suitable drive icon with RAID1 written all over it and perhaps the
icon should be named "High Availability Disk Array: 1.6TB" or "High
Performance Disk Array: 240GB" - or whatever UI folks think is sane)

> > Thus, in my view, basically, all we need is the kernel to give us the
> > name associated with a device mapper target, but I'm afraid that the
> > kernel doesn't even store this today. 
> 
> That was the next thing i wanted to publish in sysfs. The kernel does store it
> currently, but not associated with the mapping object itself. For both methods
> (syfs entry or ioctl) it needs to be reachable from the mapper object itself.

Sounds good.
  
> > 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 :-)
> 
> If sysfs had the name of the mapping, there wouldn't be a need for an ioctl by
> udev.. It would just work with a simple udev rule ;)

That would be even better, yeah.
  
> > Until that happens we may have to live with hald checking
> > that /dev/mapper/device_name has the same major/minor as the newly
> > arrived /dev/dm-0, /dev/dm-1. With all the (theoretical) races that
> > entails :-)
> 
> Maybe, depends on how open the device mapper people are to suggestions :)
> 
> I think publishing more information in sysfs about the device mapper is usefull
> anyway.. That it makes things easier for hal is just a nice coincidence :)
> 
> In the end both methods have the problem that we currently can't represent a
> device with multiple parents in hal. Any ideas about that ?
> 

Yeah, we just create the parent at the same time we create the volume;
e.g. when hald sees /dev/dm-0 and finds out, by looking at the name of
the dm target, that it's lvm2-<uuid> two new hal device objects are
added

  + Storage  <-- storage.drive_type=lvm2_raid1
   + Volume

instead of only one.

David

_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal