UdevLvmMdadmEvmsAgain

Revision 5 as of 2007-05-15 16:15:24

Clear message

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

In feisty we changed the way LVM, software raid (mdadm), EVMS, et al, interact with udev, to try to improve the situation. This was not a success and the resulting arrangements are racy.

We now propose an alternative approach which we believe will reduce (and hopefully eliminate) races.

Principle

For userspace-provided devices such as dm-* and md-* the relevant userspace tools will be responsible for device node creation and also for triggering consequential scanning.

Design

  • udev will be made to ignore kernel-generated events for devmapper and md devices.
  • the udev rendezvous functionality will be removed from libdevmapper; instead, libdevmapper will once again create device nodes itself (and we will set the default permissions to 600 root.root)
  • udev will be modified to support userspace-generated events (aka synthetic events; see below)
  • the userspace tools (lvm, mdadm, and evms, but not dmsetup) will be modified to generate synthetic udev events for each "top level" device when that device has been initialised and ready for I/O.
  • udev will respond to the synthetic event by overwriting the device node generated libdevmapper (or whatever) with one of its own with the correct ownership and permissions, using rename(2) to install it; it will also do normal vol_id scanning of the resulting device.

Details of synthetic event generation conditions

No synthetic device creation will be recorded unless atoi(getenv("UDEV_SYNTHGEN_BLOCK")). Synthetic device removal will always be recorded (and will be idempotent if there was no previously recorded synthetic device creation).

lvm will record synthetic device creation for all non-snapshot logical volumes, when activation of that LV is complete.

mdadm will record synthetic device creation for any MD device, when the device has been properly started and is ready for I/O.

dmsetup will never record synthetic device creation itself. User tools (scripts) which use dmsetup will need to be modified if automatic processing (mounting etc.) is desired. A utility will be provided to make this easy (see below).

cryptsetup will record synthetic device creation when it successfully sets the keys and makes the encrypting dm-* device available for IO.

evms will record synthetic device creation for "logical volumes" (ie storage objects which contain mountable filesystems).

The udev rules which invoke the block device identification and activation tools (ie, the ones which run when physical block devices are detected and which also now run on the synthetic device creation) will set UDEV_SYNTHGEN_BLOCK.

Rationale

This design keeps internal block devices and messings-about used by lvm and other tools, internal to those tools. It notifies the rest of the system of the availability of a new block device iff that device was automatically discovered and should be automatically used.

Udev design

A new entrypoint in libvolume_id and a corresponding command-line tool (in the volumeid package) will be made available to allow programs to record the creation and removal of synthetic devices. This librarylet entrypoint will be responsible for checking UDEV_SYNTHGEN_BLOCK (and likewise neither it nor the utility will fail if udev is not running, so that they can be used unconditionally).

This new function will work by sending udev a control messsage instructing it to create or remove the device in its device database. udevd will be made to send appropriate events in response, and will also record in its database that the device is synthetic.

udevtrigger will be made to notify udevd as well as the kernel; udevd will then regenerate the creation events for the synthetic devices in its database.


CategorySpec