Re: LVM PV UUID problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux