Ubuntu Wiki

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.

• Launchpad entry: udev-evms

• Packages affected: udev, evms

Summary

This specification details how to make udev and EVMS play nicely together, in particular ensuring that udev events are issued for EVMS volumes and that UUIDs are correctly exported and do not conflict.

Rationale

EVMS is used by system administrators to manage system block devices, combining and splitting them into logical volumes which can be readily resized and adjusted within the group without needing complicated work. In order to support event-based mounting of these filesystems, we need reliable events from the block subsystem and no race conditions.

Use cases

• Ian uses EVMS to manage his root filesystem, he would like this to continue to be supported.

Scope

The scope of this specification is limited to the interaction between udev and EVMS; other specifications address similar concerns with device-mapper, LVM, RAID, etc.

Design

EVMS is able to manage block devices ordinarily managed by both LVM and MDADM, for this reason these two services will be disabled if EVMS is installed, ideally we'd like to prevent them from being installed at all, but this has consequences for upgrades from when we used to install evms by default.

The exposed block devices are created with device-mapper, by running evms_activate. This also exposes every other block device on the system. It is safe to run multiple times, but may take a while.

Implementation

Add a udev rule to run evms_activate whenever a block device is added to the system. This should be arranged so that it is only run once at a time, and run again if another block device is added while it was being run originally.

• SUBSYSTEM=="block", RUN+="watershed /sbin/evms_activate"

The bug that caused UUIDs to point at /dev/evms devices has been already fixed in feisty.

The watershed command used in the rule above is a tool to ensure that evms_activate is run as many times as are necessary to process the incoming events. It works by locking a known filename, clearing a state file, and then running the command. If it cannot lock, it writes to the state file, and exits. When the command finishes, it checks the state file, and if it exists it loops and runs the command again.

This means that if two events come in hours apart, it is run twice. If one hundred come in in rapid sequence, it will be run at least twice, but usually not 100 times.

Notes from the actual implementation

There is a potential race between evms_activate creating the /dev/evms/* nodes and udev processing the dm event. This will be avoided by running the _same_ evms_activate watershed instance for physical devices which evms might consume and for dm devices. This rule will be made to precede the other rules which would scan the dm device for a filesystem. The dm instance event processing will thus be delayed until evms_activate is run by the second time. Note that evms_activate itself has inadequate locking for this since it doesn't wait for the lock but rather fails immediately; however, watershed will DTRT.

• -- IanJackson 8.12.2006

CategorySpec