* [linux-lvm] LVM UUIDs are not UUIDs!?
@ 2004-09-23 8:47 Ralf S. Engelschall
2004-09-23 17:10 ` Dan Stromberg
0 siblings, 1 reply; 4+ messages in thread
From: Ralf S. Engelschall @ 2004-09-23 8:47 UTC (permalink / raw)
To: linux-lvm
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
rse@engelschall.com
www.engelschall.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] LVM UUIDs are not UUIDs!?
2004-09-23 8:47 [linux-lvm] LVM UUIDs are not UUIDs!? Ralf S. Engelschall
@ 2004-09-23 17:10 ` Dan Stromberg
2004-09-23 17:53 ` Ralf S. Engelschall
0 siblings, 1 reply; 4+ messages in thread
From: Dan Stromberg @ 2004-09-23 17:10 UTC (permalink / raw)
To: rse, LVM general discussion and development
[-- Attachment #1: Type: text/plain, Size: 1805 bytes --]
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.
On Thu, 2004-09-23 at 01:47, Ralf S. Engelschall wrote:
> 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
> rse@engelschall.com
> www.engelschall.com
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
--
Dan Stromberg DCS/NACS/UCI <strombrg@dcs.nac.uci.edu>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] LVM UUIDs are not UUIDs!?
2004-09-23 17:10 ` Dan Stromberg
@ 2004-09-23 17:53 ` Ralf S. Engelschall
2004-09-25 16:41 ` Alasdair G Kergon
0 siblings, 1 reply; 4+ messages in thread
From: Ralf S. Engelschall @ 2004-09-23 17:53 UTC (permalink / raw)
To: linux-lvm
On Thu, Sep 23, 2004, Dan Stromberg wrote:
> 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.
> [...]
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
rse@engelschall.com
www.engelschall.com
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] LVM UUIDs are not UUIDs!?
2004-09-23 17:53 ` Ralf S. Engelschall
@ 2004-09-25 16:41 ` Alasdair G Kergon
0 siblings, 0 replies; 4+ messages in thread
From: Alasdair G Kergon @ 2004-09-25 16:41 UTC (permalink / raw)
To: linux-lvm
On Thu, Sep 23, 2004 at 07:53:22PM +0200, Ralf S. Engelschall wrote:
> because that's already (since many years) the official name of the
> ids from DCE 1.1 and ISO/IEC 11578:1996.
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
--
agk@redhat.com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-09-25 16:41 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-09-23 8:47 [linux-lvm] LVM UUIDs are not UUIDs!? Ralf S. Engelschall
2004-09-23 17:10 ` Dan Stromberg
2004-09-23 17:53 ` Ralf S. Engelschall
2004-09-25 16:41 ` Alasdair G Kergon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.