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

[David Zeuthen]

On Thu, 2005-01-06 at 22:34 +0000, Alasdair G Kergon wrote:
> 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
> 

OK, this is useful to know; so it should be possibly to get the name
or UUID given just the device file? E.g. the use case I'm thinking
about is that hald only gets /dev/dm-0 from udev and we're interested
in the name. 

For example, on my Fedora Core 3 system I can see that udev creates 
/dev/dm-0 and the initscripts create /dev/mapper/VolGroup00-LogVol00.
They're the same thing because the got the same major:minor number.
So, in other words, can I just do an ioctl on /dev/dm-0 and get
the name VolGroup00-LogVol00?

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

Does this cause a hotplug event? E.g., say that I have 

 /dev/mapper/VolGroup00-LogVol00

and adds a new physical volume. Then I'm guessing that the device file 
will still be called

 /dev/mapper/VolGroup00-LogVol00

but with different major:minor numbers (because of the hotplug event).
I realize it's useful to keep the name since e.g. for / one will like
to have this in the /etc/fstab file.

The reason I'm interested in this is because if we are to 
represent LVM2 volumes in HAL (to enable the same plug and play features
that we have today for normal storage devices), then we need some way 
of determining when something changes. 

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

That's useful to know, thanks.

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

OK.

Thanks,
David


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