LVM UUIDs are not UUIDs!?

While setting up an LVM2 based 3TB storage the last days I've stumbled over LVM2's "UUID" strings as displayed by its pvdisplay, vgdisplay, and lvdisplay commands. It is clear that LVM2 requires those ids, but *WHY* are they called "UUID"?

They do NOT conform in any way to the standardized ISO/IEC 11578:1996 compliant Universally Unique Identifier (UUID) strings. Neither by the way they are created (LVM2 UUIDs are just random numbers while ISO v4 random UUIDs are fixed bit-fields plus random remaining bits) nor the way they are formatted. Examples:

LVM2 UUID: H9C8iE-braW-70bk-Fx9x-lMIX-Rmmy-5XgkM9
ISO/IEC 11578:1996 UUID: 4a8287f4-0d33-11d9-8068-0002b31abd79

So, wouldn't it be reasonable that either LVM2 uses a real open-source UUID library for dealing with standardized UUIDs (ext2fs's libuuid, OSSP uuid, etc) or at least names its ids own id strings just "ID" or even "LVMID"?

Perhaps at least in the visible output strings in order to reduce confusion with standardized UUIDs...

Ralf S. Engelschall [email protected] www.engelschall.com

Same in concept, different implementation, easier to use?

The Lustre does the same thing: It has what it calls UUID's, that are actually more descriptive strings than what the standard calls for.

Dan Stromberg DCS/NACS/UCI <[email protected]>

Well, it's 100% ok if one implements own ids with more descriptive strings which are not conforming to the UUID or any other id standard. My only concern is that then the result should be better not named UUID because that's already (since many years) the official name of the ids from DCE 1.1 and ISO/IEC 11578:1996. It is like using an object addressing scheme producing strings like "foo!bar!quux" but calling them "URLs"... ;-)
Ralf S. Engelschall [email protected] www.engelschall.com

LVM2 has inherited this from LVM which calls them UUIDs. It would cause too much confusion to change this terminology.

But I'm willing to accept an LVM2 patch to uuid.c etc. which switches to generating compliant ones *provided that* it leaves the tools fully backwards- and forwards-compatible and does not introduce additional external dependencies by default.

But I have no time to spend on this myself in the forseeable future, so before it gets applied, a patch will need to be self-evidently correct (by reading it incl. comments) and have evidence of thorough testing incl. PV created by LVM1, UUID displayed correctly in old-format using the patched code; PV created with the patched code in lvm1 format, displayed correctly by LVM1 tools; PV created with patched code in lvm2 format displayed and processed sensibly by unpatched lvm2 tools etc. Also affects tools that take --uuid argument [both formats to be acceptable]; and vgexport/import, vgcfgbackup/restore, vgconvert, and even lvchange -a will need careful testing (it relies on VG and LV UUIDs), though retaining the existing length internally and introducing mapping to and from this might be a good way to limit the amount of testing necessary.

Alasdair

[email protected]