First try at improving hal's device mapper support

[David Zeuthen]

Hi Sjoerd,

sorry for the lag - I've been in Bugville and back. Somehow I think I
need
to go back there again soon :-)

Comments inline

On Tue, 2005-01-04 at 20:14 +0100, Sjoerd Simons wrote: 
> > > 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'' 
> 

OK, so what I basically mean is that just because hald sees that 
/block/sda/sda1 is the source of a mapping that involves /block/dm-0 it
doesn't mean we should go ahead and add a hal device object representing
/block/dm-0. The reason I think this is dangerous is that there is no
way
to tell why there is this mapping; it might be anything. 

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

What I'm concerned about is just adding device objects for any random 
device-mapper device and let them go through the whole fstab-sync/
g-v-m/mount chain. 

However, if there is a way to check that a given device mapper device
do correspond to a LVM2 volume (and judging from Alasdair's mail it
seems there is, yes?) that we already probed a physical volume for
in hald (e.g. there exists a volume.lvm2.uuid property of the same 
value or something), then sure, let's add it and put it through
the fstab-sync/g-v-m/mount chain. See below for more detailed thinking
about that.

Also, I'm not sure what happens when the mapping is modified; ideally,
it should mean that the old device mapper device disappears and a new 
one is added? I'm sure some experiments could tell us?

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

Sure, me too, I just don't want to break anything along the way :-)

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

That was actually a different thing... of the past.. :-)

>   
> > 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 encrypted volumes we would use the same block.storage_device as the
physical volume. So it would look like this

- Compact Flash Reader (/dev/sda)
  - Encrypted Volume (/dev/sda1) *
  - Cleartext Volume (/dev/mapper/sesame_crypto_<uuid>)

Now, the only reason we add a device object for

 /dev/mapper/sesame_crypto_<uuid>

is that the device object for * indeed has a volume.crypto_sesame.uuid
that matches the name.

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

This would look like this

- USB Hard disk (/dev/sda)
   - LVM2 physical volume (/dev/sda1) **
- USB Hard disk (/dev/sdb)
   - LVM2 phyiscal volume (/dev/sdb1) ***
- LVM2 Striped disk (/dev/mapper/VolGroupXYZ-LogVolABC)
   - LVM2 Striped volume (/dev/mapper/VolGroupXYZ-LogVolABC)

The only reason we add a device object for the device mapper device

 /dev/mapper/VolGroupXYZ-LogVolABC

is that the device objects ** and *** above both export sufficient meta
data (volume.lvm2.* properties) that guarantees that 

 /dev/mapper/VolGroupXYZ-LogVolABC

is indeed representing the logical volumes that these physical volumes
are backing. 

Now, we can't just go ahead and add a 'volume' hal device object without
telling what 'storage' hal device object it stems from; e.g. we need to
set block.storage_device to something reasonable. Why? Because that's
the
way the device model is designed. You will note that GNOME VFS uses this
so in Nautilus you will see

 Lexar CF Reader: my_volume_label

Similarly, for this example we would show

 Logical Striped Disk : label_of_fs_on_striped_volume

So we just go ahead and create the storage device at the same time we
create the volume. We set the storage.drive_type to striped_disk and
that enables e.g. GNOME VFS to select an appropriate icon. The hal
architecture is indeed designed to allow this (or rather, it happens 
to support it :-). 
 
> > (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. 
> 

No no. And don't get too attached to info.parent; you shouldn't rely on
parent/child relationships but rather that block.storage_device contains
the UDI of the storage device for this volume. That this also happens to
be the same value as info.parent is just a coincidence.

Phew, that was a long mail. I hope this clarifies how I think we should
approach enabling plug-and-play of LVM2.

Cheers,
David


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