Red Hat Bugzilla – Bug 383801
dmraid needs to generate UUIDs for lib device-mapper
Last modified: 2011-02-17 07:24:25 EST
+++ This bug was initially created as a clone of Bug #379911 +++ From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.5) Gecko/20070718 Fedora/2.0.0.5-1.fc7 Firefox/2.0.0.5 pango-text Description of problem: libdevmapper requires UUIds for mapped devices, which libdmraid doesn't generate yet. Version-Release number of selected component (if applicable): dmraid-1.0.0.rc14 How reproducible: Always Steps to Reproduce: 1. run dmraid -ay Actual Results: Expected Results: Additional info: -- Additional comment from heinzm@redhat.com on 2007-11-13 08:23 EST -- Created an attachment (id=256841) dmraid libdevmapper UUID creation patch
Created attachment 259301 [details] Patch to add UUID support to dmraid
+ /* DM_UUID_LEN is defined in dm-ioctl.h as 129 characters; + * though not all 129 must be used (md uses just 16 from + * a quick review of md.c. + * We will be using: (len vol grp name)*/ It's not obvious from glancing at those patches - please would you describe the *how* you are generating the uuids with examples of what they look like? What subsystem prefix do you propose for example?
Like the patch stands, the system wide unique RAID set name is being used. In case a subsystem prefix is mandatory, why not use "dmraid" ?
So put it in capitals, then we get: DMRAID-<unique RAID set name> alongside: LVM-<LVID> when people generate a device listing, so they can see at a glance which program created the device. Similarly if the code does any queries, it should ignore devices that don't have a uuid starting with that prefix (and the newer libdevmapper tree manipulation functions take the prefix as an argument to support that). When lvm is processing a stack of dm devices, this is how it knows at which layer to stop.
Subsystem prefix patch for dmraid filed as an attachment to Fedora 7 bz#379911 to be promoted to Fedora 8, RHEL5.2 and RHEL4.7.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Unfortunately this bugzilla was not resolved in time for RHEL 4.7 Beta. It has now been proposed for inclusion in RHEL 4.8 but must regain Product Management approval.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
The fix got into RHEL5, 6 and upstream, but not RHEL4, which has just had it's last update, so it's too late now.