* [linux-lvm] LVM PV UUID problem @ 2020-10-09 13:12 Digimer 2020-10-09 14:43 ` Zdenek Kabelac 0 siblings, 1 reply; 5+ messages in thread From: Digimer @ 2020-10-09 13:12 UTC (permalink / raw) To: linux-lvm Hi all, I'm storing LVM information in a postgres database, and wanted to use the UUID from the PVs / VGs / LVs as the UUIDs in the database. I noticed when I tried to do this that postgres complained that the UUID was not valid. I checked with an online UUID validator (https://www.freecodeformat.com/validate-uuid-guid.php) and it also reported as invalid. Example; ==== # pvdisplay | grep UUID PV UUID jLkli2-dEXx-5Y8n-pYlw-nCcy-9dFL-3B6jU3 ==== Is this a known issue? Thanks for any help/insight! -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] LVM PV UUID problem 2020-10-09 13:12 [linux-lvm] LVM PV UUID problem Digimer @ 2020-10-09 14:43 ` Zdenek Kabelac 2020-10-09 15:18 ` Digimer 0 siblings, 1 reply; 5+ messages in thread From: Zdenek Kabelac @ 2020-10-09 14:43 UTC (permalink / raw) To: LVM general discussion and development, Digimer Dne 09. 10. 20 v 15:12 Digimer napsal(a): > Hi all, > > I'm storing LVM information in a postgres database, and wanted to use > the UUID from the PVs / VGs / LVs as the UUIDs in the database. I > noticed when I tried to do this that postgres complained that the UUID > was not valid. I checked with an online UUID validator > (https://www.freecodeformat.com/validate-uuid-guid.php) and it also > reported as invalid. > > Example; > > ==== > # pvdisplay | grep UUID > PV UUID jLkli2-dEXx-5Y8n-pYlw-nCcy-9dFL-3B6jU3 > ==== > > Is this a known issue? > Hi At the time of lvm2 devel I believe UUID was just a unique identifier, later some effort to standardize it came in. But really you should NOT be using basically internal unique identifiers in your DB - this are internal to DM/LVM work and might be changed at any time to something else. User is supposed to use 'vgname' & 'lvname' - so there you can put those valid UUID sequences - although human readable strings are always nicer ;) Zdenek ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] LVM PV UUID problem 2020-10-09 14:43 ` Zdenek Kabelac @ 2020-10-09 15:18 ` Digimer 2020-10-09 15:39 ` Mark H. Wood 0 siblings, 1 reply; 5+ messages in thread From: Digimer @ 2020-10-09 15:18 UTC (permalink / raw) To: Zdenek Kabelac, LVM general discussion and development On 2020-10-09 10:43 a.m., Zdenek Kabelac wrote: > Dne 09. 10. 20 v 15:12 Digimer napsal(a): >> Hi all, >> >> I'm storing LVM information in a postgres database, and wanted to use >> the UUID from the PVs / VGs / LVs as the UUIDs in the database. I >> noticed when I tried to do this that postgres complained that the UUID >> was not valid. I checked with an online UUID validator >> (https://www.freecodeformat.com/validate-uuid-guid.php) and it also >> reported as invalid. >> >> Example; >> >> ==== >> # pvdisplay | grep UUID >> PV UUID jLkli2-dEXx-5Y8n-pYlw-nCcy-9dFL-3B6jU3 >> ==== >> >> Is this a known issue? >> > > Hi > > At the time of lvm2 devel I believe UUID was just a unique identifier, > later some effort to standardize it came in. > > But really you should NOT be using basically internal unique identifiers > in your DB - this are internal to DM/LVM work and might be changed at > any time to something else. > > User is supposed to use 'vgname' & 'lvname' - so there you can put those > valid UUID sequences - although human readable strings are always nicer ;) > > Zdenek The trick is that VG and LV names can change, so I wanted to use the (so-called) UUID as a way to keep track of a given item through name changes. I suppose I'll have to rework to use the internal "UUIDs" as more like serial numbers instead... -- Digimer Papers and Projects: https://alteeve.com/w/ "I am, somehow, less interested in the weight and convolutions of Einstein’s brain than in the near certainty that people of equal talent have lived and died in cotton fields and sweatshops." - Stephen Jay Gould ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] LVM PV UUID problem 2020-10-09 15:18 ` Digimer @ 2020-10-09 15:39 ` Mark H. Wood 2020-10-12 10:57 ` Marian Csontos 0 siblings, 1 reply; 5+ messages in thread From: Mark H. Wood @ 2020-10-09 15:39 UTC (permalink / raw) To: linux-lvm [-- Attachment #1: Type: text/plain, Size: 2286 bytes --] On Fri, Oct 09, 2020 at 11:18:38AM -0400, Digimer wrote: > On 2020-10-09 10:43 a.m., Zdenek Kabelac wrote: > > Dne 09. 10. 20 v 15:12 Digimer napsal(a): > >> Hi all, > >> > >> I'm storing LVM information in a postgres database, and wanted to use > >> the UUID from the PVs / VGs / LVs as the UUIDs in the database. I > >> noticed when I tried to do this that postgres complained that the UUID > >> was not valid. I checked with an online UUID validator > >> (https://www.freecodeformat.com/validate-uuid-guid.php) and it also > >> reported as invalid. > >> > >> Example; > >> > >> ==== > >> # pvdisplay | grep UUID > >> PV UUID jLkli2-dEXx-5Y8n-pYlw-nCcy-9dFL-3B6jU3 > >> ==== > >> > >> Is this a known issue? > >> > > > > Hi > > > > At the time of lvm2 devel I believe UUID was just a unique identifier, > > later some effort to standardize it came in. > > > > But really you should NOT be using basically internal unique identifiers > > in your DB - this are internal to DM/LVM work and might be changed at > > any time to something else. > > > > User is supposed to use 'vgname' & 'lvname' - so there you can put those > > valid UUID sequences - although human readable strings are always nicer ;) > > > > Zdenek > > The trick is that VG and LV names can change, so I wanted to use the > (so-called) UUID as a way to keep track of a given item through name > changes. > > I suppose I'll have to rework to use the internal "UUIDs" as more like > serial numbers instead... Well, if we are stuck with non-standard "UUID"s, at least they are meant to be Universally Unique, so they can be treated as unique opaque string tokens. Or you might find a library function that can return the unencoded binary value and you can encode it as you please. However, the issue of persistence remains. FWIW I think it's quite reasonable for someone to want immutable unique identifiers for distinct objects such as LVM PVs, especially when the "unique identifier" part is already available and quite visible. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] LVM PV UUID problem 2020-10-09 15:39 ` Mark H. Wood @ 2020-10-12 10:57 ` Marian Csontos 0 siblings, 0 replies; 5+ messages in thread From: Marian Csontos @ 2020-10-12 10:57 UTC (permalink / raw) To: linux-lvm On 10/9/20 5:39 PM, Mark H. Wood wrote: > On Fri, Oct 09, 2020 at 11:18:38AM -0400, Digimer wrote: >> On 2020-10-09 10:43 a.m., Zdenek Kabelac wrote: >>> Dne 09. 10. 20 v 15:12 Digimer napsal(a): >>>> Hi all, >>>> >>>> �� I'm storing LVM information in a postgres database, and wanted to use >>>> the UUID from the PVs / VGs / LVs as the UUIDs in the database. I >>>> noticed when I tried to do this that postgres complained that the UUID >>>> was not valid. I checked with an online UUID validator >>>> (https://www.freecodeformat.com/validate-uuid-guid.php) and it also >>>> reported as invalid. >>>> >>>> Example; >>>> >>>> ==== >>>> # pvdisplay | grep UUID >>>> �� PV UUID�������������� jLkli2-dEXx-5Y8n-pYlw-nCcy-9dFL-3B6jU3 >>>> ==== >>>> >>>> �� Is this a known issue? >>>> >>> >>> Hi >>> >>> At the time of lvm2 devel I believe UUID was just a unique identifier, >>> later some effort to standardize it came in. >>> >>> But really you should NOT be using basically internal unique identifiers >>> in your DB - this are internal to DM/LVM work and might be changed at >>> any time to something else. >>> >>> User is supposed to use� 'vgname' & 'lvname'� - so there you can put those >>> valid UUID sequences - although human readable strings are always nicer ;) >>> >>> Zdenek >> >> The trick is that VG and LV names can change, so I wanted to use the >> (so-called) UUID as a way to keep track of a given item through name >> changes. >> >> I suppose I'll have to rework to use the internal "UUIDs" as more like >> serial numbers instead... > > Well, if we are stuck with non-standard "UUID"s, at least they are > meant to be Universally Unique, so they can be treated as unique > opaque string tokens. Or you might find a library function that can > return the unencoded binary value and you can encode it as you please. > However, the issue of persistence remains. > > FWIW I think it's quite reasonable for someone to want immutable > unique identifiers for distinct objects such as LVM PVs, especially > when the "unique identifier" part is already available and quite > visible. ...and then there is lvconvert which takes existing LV and creates a new object with the same name, and original LV is used as a "compnent" (e.g. raid1 leg, or snapshot origin) So now there are two objects, one with the same name, and other one - the original LV, which one should use the original UUID? Just consider LVM UUIDs as MUST BE unique IDs. Or better MUST BE for lvm to work properly, and SHOULD BE in reality (as duplicates occur e.g. when SAN snapshots are visible to the system and you run into troubles, and so there are filters,...) -- Martian > > > _______________________________________________ > 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/ > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-10-12 10:57 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-09 13:12 [linux-lvm] LVM PV UUID problem Digimer 2020-10-09 14:43 ` Zdenek Kabelac 2020-10-09 15:18 ` Digimer 2020-10-09 15:39 ` Mark H. Wood 2020-10-12 10:57 ` Marian Csontos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).