First try at improving hal's device mapper support

Tue Jan 4 11:14:28 PST 2005

On Mon, Jan 03, 2005 at 10:34:20AM -0500, David Zeuthen wrote:
> 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? 

Don't understand what you mean with ``volume backing it is the source'' 

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

Iirc the power of lvm2 comes from changing the mapping right.. So why you want
to do that as a contract ? Could you explain what guarantees we could get from
such a contract, which are needed for hal to support devmapper/lvm2 the right
way ?

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

Having stuff just work is always okay :).. But i would like hal to always have
a sensible representation of the system, no matter how it is setup. 

What you could do is to tag volumes that follow your ``contract'' tagged in 
someway by hal... So some tools using hal can choose to only handle those 
volumes and other can still have a sensible represantation of all volumes.

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

Oh, you mean the devices that hal-device-manager called virtual. Then i
understand what you mean :)

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

So your encrypted volume will have the ``/dev/sda'' as parent instead of
``/dev/dm-0'' for example ?

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

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

Just to mention another possibility. Would it be possible to redefine
info.parent as an array (or have info.parents when there are multible)? Seems
somewhat more natural to me. 

  Sjoerd
-- 
Life is knowing how far to go without crossing the line.
_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal