[linux-lvm] fixing mangled UUIDs

[linux-lvm] fixing mangled UUIDs

[John Stoffel]

I've got a Debian Jessie system running Linux kernel 4.4-rc4 on AMD64
Phenom II X4 with 16gb of RAM.  I've just replaced a bunch of failing
1Tb drives and my 320Gb boot drives with 2 x 4Tb disks and 2 x 500gb
SSDs.  Using LVM cache for a couple of areas and it's looking good so
far.  I've got the following LVM targets:

   # dmsetup targets
   cache            v1.8.0
   thin-pool        v1.16.0
   thin             v1.16.0
   raid             v1.7.0
   zero             v1.1.0
   mirror           v1.14.0
   snapshot-merge   v1.4.0
   snapshot-origin  v1.9.0
   snapshot         v1.15.0
   multipath        v1.10.0
   flakey           v1.3.1
   delay            v1.2.1
   crypt            v1.14.1
   striped          v1.5.1
   linear           v1.2.1
   error            v1.3.0

And packages installed:

  libllvm3.5:amd64        1:3.5-10
  liblvm2app2.2:amd64     2.02.111-2.2
  liblvm2cmd2.02:amd64    2.02.111-2.2
  lvm2    2.02.111-2.2

So now I want to monitor performance and cache usage.  But I can't
because:

  dmsetup status --target cache

Fails with:

The UUID
"LVM-HWDbRMPFL85!mVbEi4wru5#G7YfWK3wVas2sZsZM8mw0VXDgx03ryaq351RUEL4j-cmeta"
should be mangled but it contains blacklisted characters.
The UUID
"LVM-HWDbRMPFL85!mVbEi4wru5#G7YfWK3wVbbcg3pVFZyDngdRLS4aECbc571Lyb5MI"
should be mangled but it contains blacklisted characters.
Command failed


So I've looked at dmsetup man page and tried to run

   dmsetup mangle

But it fails on all the LVM volumes with stuff like this:

   data-pete:
   LVM-HWDbRMPFL85!mVbEi4wru5#G7YfWK3wVbbcg3pVFZyDngdRLS4aECbc571Lyb5MI:
   UUID in incorrect form.
   Unable to change device UUID. The device must be deactivated first.
   Command failed

So when I do:

  umount /mnt/pete
  lvchange -an data/pete
  dmsetup mangle data/pete

it bombs out.  I've compiled the latest lvm2 tools, but it still dies:

  # /opt/lvm2/sbin/dmsetup --version
  Library version:   1.02.114-git (2015-12-05)
  Driver version:    4.34.0

So I have two questions:

1. How do I mangle the name properly?  Do I need to reboot using a
   LiveCD of some sort?

2. And can we fix the failing of: dmsetup status --target-cache even
when there are UUIDs that need de-mangling?

I'm happy to test patches, versions, etc.

THanks,
John

fixing mangled UUIDs

[John Stoffel]

I've got a Debian Jessie system running Linux kernel 4.4-rc4 on AMD64
Phenom II X4 with 16gb of RAM.  I've just replaced a bunch of failing
1Tb drives and my 320Gb boot drives with 2 x 4Tb disks and 2 x 500gb
SSDs.  Using LVM cache for a couple of areas and it's looking good so
far.  I've got the following LVM targets:

   # dmsetup targets
   cache            v1.8.0
   thin-pool        v1.16.0
   thin             v1.16.0
   raid             v1.7.0
   zero             v1.1.0
   mirror           v1.14.0
   snapshot-merge   v1.4.0
   snapshot-origin  v1.9.0
   snapshot         v1.15.0
   multipath        v1.10.0
   flakey           v1.3.1
   delay            v1.2.1
   crypt            v1.14.1
   striped          v1.5.1
   linear           v1.2.1
   error            v1.3.0

And packages installed:

  libllvm3.5:amd64        1:3.5-10
  liblvm2app2.2:amd64     2.02.111-2.2
  liblvm2cmd2.02:amd64    2.02.111-2.2
  lvm2    2.02.111-2.2

So now I want to monitor performance and cache usage.  But I can't
because:

  dmsetup status --target cache

Fails with:

The UUID
"LVM-HWDbRMPFL85!mVbEi4wru5#G7YfWK3wVas2sZsZM8mw0VXDgx03ryaq351RUEL4j-cmeta"
should be mangled but it contains blacklisted characters.
The UUID
"LVM-HWDbRMPFL85!mVbEi4wru5#G7YfWK3wVbbcg3pVFZyDngdRLS4aECbc571Lyb5MI"
should be mangled but it contains blacklisted characters.
Command failed


So I've looked at dmsetup man page and tried to run

   dmsetup mangle

But it fails on all the LVM volumes with stuff like this:

   data-pete:
   LVM-HWDbRMPFL85!mVbEi4wru5#G7YfWK3wVbbcg3pVFZyDngdRLS4aECbc571Lyb5MI:
   UUID in incorrect form.
   Unable to change device UUID. The device must be deactivated first.
   Command failed

So when I do:

  umount /mnt/pete
  lvchange -an data/pete
  dmsetup mangle data/pete

it bombs out.  I've compiled the latest lvm2 tools, but it still dies:

  # /opt/lvm2/sbin/dmsetup --version
  Library version:   1.02.114-git (2015-12-05)
  Driver version:    4.34.0

So I have two questions:

1. How do I mangle the name properly?  Do I need to reboot using a
   LiveCD of some sort?

2. And can we fix the failing of: dmsetup status --target-cache even
when there are UUIDs that need de-mangling?

I'm happy to test patches, versions, etc.

THanks,
John

Re: [linux-lvm] [dm-devel] fixing mangled UUIDs

[Alasdair G Kergon]

Have you tried '--manglename none' if you aren't using a udev system that
mangles names?  (Also available via environmnet variable - see man page.)

Alasdair

Re: fixing mangled UUIDs

[Alasdair G Kergon]

Have you tried '--manglename none' if you aren't using a udev system that
mangles names?  (Also available via environmnet variable - see man page.)

Alasdair

Re: [linux-lvm] [dm-devel] fixing mangled UUIDs

[John Stoffel]

Alasdair> Have you tried '--manglename none' if you aren't using a
Alasdair> udev system that mangles names?  (Also available via
Alasdair> environmnet variable - see man page.)

That seems to be working, using the default Debbian Jessie lvm tools:

  dmsetup --manglename none status --target cache
  data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
  350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
  smq 0 rw -
  data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
  1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -


So now I can try to monitor my cache usage.

So the question still remains, what is the long term fix so I don't
have to deal with this breakage by default?  Do I have bad UUIDS on my
volumes?

John

Re: fixing mangled UUIDs

[John Stoffel]

Alasdair> Have you tried '--manglename none' if you aren't using a
Alasdair> udev system that mangles names?  (Also available via
Alasdair> environmnet variable - see man page.)

That seems to be working, using the default Debbian Jessie lvm tools:

  dmsetup --manglename none status --target cache
  data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
  350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
  smq 0 rw -
  data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
  1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -


So now I can try to monitor my cache usage.

So the question still remains, what is the long term fix so I don't
have to deal with this breakage by default?  Do I have bad UUIDS on my
volumes?

John

Re: [linux-lvm] fixing mangled UUIDs

[Zdenek Kabelac]

Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>
> Alasdair> Have you tried '--manglename none' if you aren't using a
> Alasdair> udev system that mangles names?  (Also available via
> Alasdair> environmnet variable - see man page.)
>
> That seems to be working, using the default Debbian Jessie lvm tools:
>
>    dmsetup --manglename none status --target cache
>    data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>    350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>    smq 0 rw -
>    data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>    1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>
>
> So now I can try to monitor my cache usage.
>
> So the question still remains, what is the long term fix so I don't
> have to deal with this breakage by default?  Do I have bad UUIDS on my
> volumes?
>


Yep

See supported charset:

--
Mangle any character not on a whitelist using mangling_mode when processing 
device-mapper device names and UUIDs. The names and UUIDs are mangled on 
input  and unmangled  on  output  where  the  mangling  mode  is one of: auto 
(only do the mangling if not mangled yet, do nothing if already mangled, error 
on mixed), hex (always do the mangling) and none (no mangling).  Default mode 
is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also 
supported by udev. Any  character  not  on  a  whitelist  is replaced with its 
hex value (two digits) prefixed by \x.  Mangling mode could be also set 
through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
---

Udev create symlinks from UUID - so they need to be using udev-supported
chars - and you   '!' in UUID -> unsupported and needs mangling.

Regards

Zdenek

Re: fixing mangled UUIDs

[Zdenek Kabelac]

Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>
> Alasdair> Have you tried '--manglename none' if you aren't using a
> Alasdair> udev system that mangles names?  (Also available via
> Alasdair> environmnet variable - see man page.)
>
> That seems to be working, using the default Debbian Jessie lvm tools:
>
>    dmsetup --manglename none status --target cache
>    data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>    350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>    smq 0 rw -
>    data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>    1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>
>
> So now I can try to monitor my cache usage.
>
> So the question still remains, what is the long term fix so I don't
> have to deal with this breakage by default?  Do I have bad UUIDS on my
> volumes?
>


Yep

See supported charset:

--
Mangle any character not on a whitelist using mangling_mode when processing 
device-mapper device names and UUIDs. The names and UUIDs are mangled on 
input  and unmangled  on  output  where  the  mangling  mode  is one of: auto 
(only do the mangling if not mangled yet, do nothing if already mangled, error 
on mixed), hex (always do the mangling) and none (no mangling).  Default mode 
is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also 
supported by udev. Any  character  not  on  a  whitelist  is replaced with its 
hex value (two digits) prefixed by \x.  Mangling mode could be also set 
through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
---

Udev create symlinks from UUID - so they need to be using udev-supported
chars - and you   '!' in UUID -> unsupported and needs mangling.

Regards

Zdenek

Re: [linux-lvm] [dm-devel] fixing mangled UUIDs

[John Stoffel]

>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:

Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>> 
Alasdair> Have you tried '--manglename none' if you aren't using a
Alasdair> udev system that mangles names?  (Also available via
Alasdair> environmnet variable - see man page.)
>> 
>> That seems to be working, using the default Debbian Jessie lvm tools:
>> 
>> dmsetup --manglename none status --target cache
>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>> smq 0 rw -
>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>> 
>> 
>> So now I can try to monitor my cache usage.
>> 
>> So the question still remains, what is the long term fix so I don't
>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>> volumes?

Zdenek> Yep

Zdenek> See supported charset:

Zdenek> --
Zdenek> Mangle any character not on a whitelist using mangling_mode when processing 
Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on 
Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto 
Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error 
Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode 
Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also 
Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its 
Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set 
Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
Zdenek> ---

Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.

I'm happy to fix the UUIDs, the question is HOW.  Ideally without
having to shutdown the system.

As I explained in my earlier email, I tried using 'lvchange -an
data/pete' to disable one of my LVs (after unmounting it) but then I
can't see it to manage it with dmsetup to fix the UUIDs.

John

Re: [dm-devel] fixing mangled UUIDs

[John Stoffel]

>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:

Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>> 
Alasdair> Have you tried '--manglename none' if you aren't using a
Alasdair> udev system that mangles names?  (Also available via
Alasdair> environmnet variable - see man page.)
>> 
>> That seems to be working, using the default Debbian Jessie lvm tools:
>> 
>> dmsetup --manglename none status --target cache
>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>> smq 0 rw -
>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>> 
>> 
>> So now I can try to monitor my cache usage.
>> 
>> So the question still remains, what is the long term fix so I don't
>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>> volumes?

Zdenek> Yep

Zdenek> See supported charset:

Zdenek> --
Zdenek> Mangle any character not on a whitelist using mangling_mode when processing 
Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on 
Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto 
Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error 
Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode 
Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also 
Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its 
Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set 
Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
Zdenek> ---

Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.

I'm happy to fix the UUIDs, the question is HOW.  Ideally without
having to shutdown the system.

As I explained in my earlier email, I tried using 'lvchange -an
data/pete' to disable one of my LVs (after unmounting it) but then I
can't see it to manage it with dmsetup to fix the UUIDs.

John

_______________________________________________
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/

Re: [linux-lvm] [dm-devel] fixing mangled UUIDs

[Zdenek Kabelac]

Dne 9.12.2015 v 21:39 John Stoffel napsal(a):
>>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:
>
> Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>>>
> Alasdair> Have you tried '--manglename none' if you aren't using a
> Alasdair> udev system that mangles names?  (Also available via
> Alasdair> environmnet variable - see man page.)
>>>
>>> That seems to be working, using the default Debbian Jessie lvm tools:
>>>
>>> dmsetup --manglename none status --target cache
>>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>>> smq 0 rw -
>>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>>>
>>>
>>> So now I can try to monitor my cache usage.
>>>
>>> So the question still remains, what is the long term fix so I don't
>>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>>> volumes?
>
> Zdenek> Yep
>
> Zdenek> See supported charset:
>
> Zdenek> --
> Zdenek> Mangle any character not on a whitelist using mangling_mode when processing
> Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on
> Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto
> Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error
> Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode
> Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also
> Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its
> Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set
> Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
> Zdenek> ---
>
> Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
> Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.
>
> I'm happy to fix the UUIDs, the question is HOW.  Ideally without
> having to shutdown the system.
>
> As I explained in my earlier email, I tried using 'lvchange -an
> data/pete' to disable one of my LVs (after unmounting it) but then I
> can't see it to manage it with dmsetup to fix the UUIDs.
>


dmsetup remove  unwanted-vg-lv-name


vgcfgbackup

vim   and fix UUID  (replace ! char) by hand

vgcfgrestore



Regard

Zdenek

Re: fixing mangled UUIDs

[Zdenek Kabelac]

Dne 9.12.2015 v 21:39 John Stoffel napsal(a):
>>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:
>
> Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>>>
> Alasdair> Have you tried '--manglename none' if you aren't using a
> Alasdair> udev system that mangles names?  (Also available via
> Alasdair> environmnet variable - see man page.)
>>>
>>> That seems to be working, using the default Debbian Jessie lvm tools:
>>>
>>> dmsetup --manglename none status --target cache
>>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>>> smq 0 rw -
>>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>>>
>>>
>>> So now I can try to monitor my cache usage.
>>>
>>> So the question still remains, what is the long term fix so I don't
>>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>>> volumes?
>
> Zdenek> Yep
>
> Zdenek> See supported charset:
>
> Zdenek> --
> Zdenek> Mangle any character not on a whitelist using mangling_mode when processing
> Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on
> Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto
> Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error
> Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode
> Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also
> Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its
> Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set
> Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
> Zdenek> ---
>
> Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
> Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.
>
> I'm happy to fix the UUIDs, the question is HOW.  Ideally without
> having to shutdown the system.
>
> As I explained in my earlier email, I tried using 'lvchange -an
> data/pete' to disable one of my LVs (after unmounting it) but then I
> can't see it to manage it with dmsetup to fix the UUIDs.
>


dmsetup remove  unwanted-vg-lv-name


vgcfgbackup

vim   and fix UUID  (replace ! char) by hand

vgcfgrestore



Regard

Zdenek

Re: [linux-lvm] [dm-devel] fixing mangled UUIDs

[John Stoffel]

>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:

Zdenek> Dne 9.12.2015 v 21:39 John Stoffel napsal(a):
>>>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:
>> 
Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>>>> 
Alasdair> Have you tried '--manglename none' if you aren't using a
Alasdair> udev system that mangles names?  (Also available via
Alasdair> environmnet variable - see man page.)
>>>> 
>>>> That seems to be working, using the default Debbian Jessie lvm tools:
>>>> 
>>>> dmsetup --manglename none status --target cache
>>>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>>>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>>>> smq 0 rw -
>>>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>>>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>>>> 
>>>> 
>>>> So now I can try to monitor my cache usage.
>>>> 
>>>> So the question still remains, what is the long term fix so I don't
>>>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>>>> volumes?
>> 
Zdenek> Yep
>> 
Zdenek> See supported charset:
>> 
Zdenek> --
Zdenek> Mangle any character not on a whitelist using mangling_mode when processing
Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on
Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto
Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error
Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode
Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also
Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its
Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set
Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
Zdenek> ---
>> 
Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.
>> 
>> I'm happy to fix the UUIDs, the question is HOW.  Ideally without
>> having to shutdown the system.
>> 
>> As I explained in my earlier email, I tried using 'lvchange -an
>> data/pete' to disable one of my LVs (after unmounting it) but then I
>> can't see it to manage it with dmsetup to fix the UUIDs.
>> 


Zdenek> dmsetup remove  unwanted-vg-lv-name


Zdenek> vgcfgbackup

Zdenek> vim   and fix UUID  (replace ! char) by hand

Zdenek> vgcfgrestore

Awesome, but can I do this with the system live?  Or do I need to boot
into a rescue CD to make this?  Hidden assumptions are the killer
here.

Re: [linux-lvm] fixing mangled UUIDs

[John Stoffel]

>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:

Zdenek> Dne 9.12.2015 v 21:39 John Stoffel napsal(a):
>>>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:
>> 
Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>>>> 
Alasdair> Have you tried '--manglename none' if you aren't using a
Alasdair> udev system that mangles names?  (Also available via
Alasdair> environmnet variable - see man page.)
>>>> 
>>>> That seems to be working, using the default Debbian Jessie lvm tools:
>>>> 
>>>> dmsetup --manglename none status --target cache
>>>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>>>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>>>> smq 0 rw -
>>>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>>>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>>>> 
>>>> 
>>>> So now I can try to monitor my cache usage.
>>>> 
>>>> So the question still remains, what is the long term fix so I don't
>>>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>>>> volumes?
>> 
Zdenek> Yep
>> 
Zdenek> See supported charset:
>> 
Zdenek> --
Zdenek> Mangle any character not on a whitelist using mangling_mode when processing
Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on
Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto
Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error
Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode
Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also
Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its
Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set
Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
Zdenek> ---
>> 
Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.
>> 
>> I'm happy to fix the UUIDs, the question is HOW.  Ideally without
>> having to shutdown the system.
>> 
>> As I explained in my earlier email, I tried using 'lvchange -an
>> data/pete' to disable one of my LVs (after unmounting it) but then I
>> can't see it to manage it with dmsetup to fix the UUIDs.
>> 


Zdenek> dmsetup remove  unwanted-vg-lv-name


Zdenek> vgcfgbackup

Zdenek> vim   and fix UUID  (replace ! char) by hand

Zdenek> vgcfgrestore

Awesome, but can I do this with the system live?  Or do I need to boot
into a rescue CD to make this?  Hidden assumptions are the killer
here.

Re: [linux-lvm] fixing mangled UUIDs

[Zdenek Kabelac]

Dne 10.12.2015 v 16:15 John Stoffel napsal(a):
>>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:
>
> Zdenek> Dne 9.12.2015 v 21:39 John Stoffel napsal(a):
>>>>>>>> "Zdenek" == Zdenek Kabelac <zdenek.kabelac@gmail.com> writes:
>>>
> Zdenek> Dne 9.12.2015 v 17:40 John Stoffel napsal(a):
>>>>>
> Alasdair> Have you tried '--manglename none' if you aren't using a
> Alasdair> udev system that mangles names?  (Also available via
> Alasdair> environmnet variable - see man page.)
>>>>>
>>>>> That seems to be working, using the default Debbian Jessie lvm tools:
>>>>>
>>>>> dmsetup --manglename none status --target cache
>>>>> data-home: 0 1153433600 cache 8 2443/32768 128 54020/819200 80721
>>>>> 350897 64427 66938 0 23882 1 1 writeback 2 migration_threshold 2048
>>>>> smq 0 rw -
>>>>> data-local: 0 702545920 cache 8 2443/32768 128 1078/819200 6268 85795
>>>>> 1492 2715 0 1057 0 1 writeback 2 migration_threshold 2048 smq 0 rw -
>>>>>
>>>>>
>>>>> So now I can try to monitor my cache usage.
>>>>>
>>>>> So the question still remains, what is the long term fix so I don't
>>>>> have to deal with this breakage by default?  Do I have bad UUIDS on my
>>>>> volumes?
>>>
> Zdenek> Yep
>>>
> Zdenek> See supported charset:
>>>
> Zdenek> --
> Zdenek> Mangle any character not on a whitelist using mangling_mode when processing
> Zdenek> device-mapper device names and UUIDs. The names and UUIDs are mangled on
> Zdenek> input  and unmangled  on  output  where  the  mangling  mode  is one of: auto
> Zdenek> (only do the mangling if not mangled yet, do nothing if already mangled, error
> Zdenek> on mixed), hex (always do the mangling) and none (no mangling).  Default mode
> Zdenek> is auto.  Character whitelist: 0-9, A-Z, a-z, #+-.:=@_. This whitelist is also
> Zdenek> supported by udev. Any  character  not  on  a  whitelist  is replaced with its
> Zdenek> hex value (two digits) prefixed by \x.  Mangling mode could be also set
> Zdenek> through DM_DEFAULT_NAME_MANGLING_MODE environment variable.
> Zdenek> ---
>>>
> Zdenek> Udev create symlinks from UUID - so they need to be using udev-supported
> Zdenek> chars - and you   '!' in UUID -> unsupported and needs mangling.
>>>
>>> I'm happy to fix the UUIDs, the question is HOW.  Ideally without
>>> having to shutdown the system.
>>>
>>> As I explained in my earlier email, I tried using 'lvchange -an
>>> data/pete' to disable one of my LVs (after unmounting it) but then I
>>> can't see it to manage it with dmsetup to fix the UUIDs.
>>>
>
>
> Zdenek> dmsetup remove  unwanted-vg-lv-name
>
>
> Zdenek> vgcfgbackup
>
> Zdenek> vim   and fix UUID  (replace ! char) by hand
>
> Zdenek> vgcfgrestore
>
> Awesome, but can I do this with the system live?  Or do I need to boot
> into a rescue CD to make this?  Hidden assumptions are the killer
> here.


Yes - should be safe - as long as you  will not try to modify more things in 
parallel.

Anyway - this issue will need upstream fix.
But if you need something 'right now' - use the above sequence.

Regards

Zdenek