implementation turns out not to exist atm
|Deletions are marked like this.||Additions are marked like this.|
|Line 46:||Line 46:|
|mdadm -C -n2 -lstripe -amd /dev/md/tstripe /dev/gusb/vmd0 /dev/gusb/vmd1|
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-mdadm udev-mdadm]
Packages affected: udev, mdadm
This specification details how to make udev and mdadm play nicely together, in particular ensuring that udev events are issued for mdadm volumes and that UUIDs are correctly exported and do not conflict.
mdadm is used by system administrators to perform RAID operations such as mirroring or striping without hardware support. In order to support event-based mounting of these filesystems, we need reliable events from the block subsystem and no race conditions.
- Jerry is a system administrator who uses software raid, via mdadm, for his root filesystem. He would like this to continue to be supported.
The scope of this specification is limited to the interaction between udev and mdadm; other specifications address similar concerns with device-mapper, LVM, etc.
Most of the work for this to be supported has been done in Debian, ensuring that mdadm is run on udev events for the md block devices.
A bug in edgy that exposed the UUID of the component blocks of the RAID collection has been already fixed for feisty.
The UUID of the RAID itself can be exposed, as we receive udev events for when the md device is created or changed.
- Merge mdadm from Debian.
- Upload udev 103.
The above comments turn out not to be true any more; the udev mdadm support in Debian appears to have been reverted. (-iwj 6.2.2007)
mdadm -A mdadm -C -n2 -lstripe -amd /dev/md/tstripe /dev/gusb/vmd0 /dev/gusb/vmd1