UdevEvms
|
Size: 2917
Comment: describe watershed
|
Size: 2922
Comment: s/vgchange/evms_activate/
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 42: | Line 42: |
| The `watershed` command used in the rule above is a tool to ensure that `vgchange` 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. If the state file does not exist. | 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. If the state file does not exist. |
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: [https://features.launchpad.net/distros/ubuntu/+spec/udev-evms 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. If the state file does not exist.
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.
UdevEvms (last edited 2008-08-06 16:32:05 by localhost)