[linux-lvm] what creates the symlinks in /dev/<volgroup> ?

[Zdenek Kabelac]

Dne 23.6.2016 v 18:35 Chris Friesen napsal(a):
> On 06/23/2016 02:34 AM, Zdenek Kabelac wrote:
>> Dne 22.6.2016 v 16:52 Chris Friesen napsal(a):
>>> On 06/22/2016 03:23 AM, Zdenek Kabelac wrote:
>>>> Dne 21.6.2016 v 17:22 Chris Friesen napsal(a):
>>>>> I'm using the stock CentOS7 version, I think.
>>>>>
>>>>>   LVM version:     2.02.130(2)-RHEL7 (2015-12-01)
>>>>>   Library version: 1.02.107-RHEL7 (2015-12-01)
>>>>>   Driver version:  4.33.0
>>>>>
>>>>> So are you saying that nobody should run "vgscan --mknodes" on a system
>>>>> where
>>>>> udev is managing the symlinks?
>>>>
>>>> Yes - on such system this command should be used only in case of 'emergency',
>>>> udev doesn't work properly and you need links.
>>>>
>>>> The links however will not be known to udev and likely whole system is
>>>> going to be crashing soon or is misconfigured in major way.
>>>
>>> Okay, I'll see if I can get the call to vgscan removed.  But even so wouldn't
>>> it make sense to have vgscan use the same logic as udev in terms of what
>>> symlinks to make and where to make them to?
>>
>> It *IS* using same logic.
>>
>> If the link is not there - the bug is in your udev rules.
>>
>> When udev is properly configured, vgscan should not show missing link.
>
> It doesn't seem to work this way in practice on a stock CentOS system.  Here's
> the sequence:
>
> 1) create a volume group:
> "vgcreate chris-volumes /dev/loop2"
> At this point there is no /dev/chris-volumes directory.
>

ONLY  active volume do have links

Never ever there is supposed to be directory entry for VG without any active LV.

There is not a term 'active VG' as such - it always is in connection with 
active LV - thus directory without any active LV inside is pure bug - if you 
see it - report it as regular BZ..



> 2) Create a thin pool in the volume group:
> "lvcreate -L 1.8GB -T chris-volumes/chris-volumes-pool"
>
> Now udev creates a /dev/chris-volumes directory with a link for the thin pool:
> [root at centos7 centos]# ls -l /dev/chris-volumes
> total 0
> lrwxrwxrwx. 1 root root 7 Jun 23 12:22 chris-volumes-pool -> ../dm-9
>
> 3) Create a thin volume in the thin pool:
> "lvcreate -V1G -T chris-volumes/chris-volumes-pool -n thinvolume"
>
> Now the link for the thin pool itself has disappeared:
> [root at centos7 centos]# ls -l /dev/chris-volumes
> total 0
> lrwxrwxrwx. 1 root root 8 Jun 23 12:23 thinvolume -> ../dm-11
>
> (At this point /dev/mapper/chris--volumes-chris--volumes--pool-tpool points to
> dm-9 and /dev/mapper/chris--volumes-chris--volumes--pool points to dm-10.)

correct

> 4) If I run "vgscan --mknodes", it re-creates the thin pool link, but pointing
> to the /dev/mapper name instead of directly to the /dev/dm-*.  Also, it's
> indirectly pointing to /dev/dm-10 where before it was pointing to /dev/dm-9:

Only 'final' resolving device does matter.

if link is     /dev/vg/lv  ->   /dev/mapper/vg-lv   ->  /dev/dm-XXX
or   /dev/vg/lv  ->  /dev/dm-XXX  - it does not matter.

There are some 'tricks' related to thin-pool maintainance.

Unused  thin-pool is 'public' LV - has  /dev/vg/lv   link.
Used thin-pool by lvm2 is 'private'  LV -   doesn't have  /dev/vg/lv  link.

All device should always have entry in  /dev/mapper/ - either links
to real devices or direct nodes (on older systems)

lvm2 users are always supposed to use ONLY /dev/vg/lv  devices for access.




>
> [root at centos7 centos]# vgscan --mknodes
>   Configuration setting "snapshot_autoextend_percent" invalid. It's not part
> of any section.
>   Configuration setting "snapshot_autoextend_threshold" invalid. It's not part
> of any section.

fix your lvm.conf   (uncomment sections)

>   Reading all physical volumes.  This may take a while...
>   Found volume group "chris-volumes" using metadata type lvm2
>   Found volume group "centos" using metadata type lvm2
>   Found volume group "cinder-volumes" using metadata type lvm2
>   The link /dev/chris-volumes/chris-volumes-pool should have been created by

Ok - there seems to be internal bug in lvm2 - which incorrectly hints
link creation for this case.

There should not have been  /dev/vg/pool link - this is correctly marked
for udev - but incorrectly for udev validation.

However the bug is actually not so much important - it just links
to 'wrapper' device - and eventually we will resolve the problem even without 
this extra device in table.


Regards

Zdenek