From: Chris Friesen <chris.friesen@windriver.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] what creates the symlinks in /dev/<volgroup> ?
Date: Thu, 23 Jun 2016 10:35:59 -0600 [thread overview]
Message-ID: <576C0FEF.7060301@windriver.com> (raw)
In-Reply-To: <ae18c007-f3ed-5115-b563-8a1074f27151@redhat.com>
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.
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@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@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.)
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:
[root@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.
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
udev but it was not found. Falling back to direct link creation.
[root@centos7 centos]# ls -l /dev/chris-volumes
total 0
lrwxrwxrwx. 1 root root 47 Jun 23 12:25 chris-volumes-pool ->
/dev/mapper/chris--volumes-chris--volumes--pool
lrwxrwxrwx. 1 root root 8 Jun 23 12:23 thinvolume -> ../dm-11
5) If I run "vgchange -an chris-volumes", I'm left with a /dev/chris-volumes
directory containing a broken symlink (broken because
/dev/mapper/chris--volumes-chris--volumes--pool doesn't exist anymore):
[root@centos7 centos]# ls -l /dev/chris-volumes
total 0
lrwxrwxrwx. 1 root root 47 Jun 23 12:25 chris-volumes-pool ->
/dev/mapper/chris--volumes-chris--volumes--pool
It looks like /usr/lib/udev/rules.d/11-dm-lvm.rules is what makes the
/dev/<VG>/<LV> symlink for normal devices, but for a thin pool with a thin
volume in it it will exit without making a symlink because
DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1 is set.
[root@centos7 centos]# udevadm info /dev/chris-volumes/chris-volumes-pool
P: /devices/virtual/block/dm-10
N: dm-10
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
Chris
next prev parent reply other threads:[~2016-06-23 16:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 20:52 [linux-lvm] what creates the symlinks in /dev/<volgroup> ? Chris Friesen
2016-06-20 21:03 ` Ilya Boka
2016-06-20 21:53 ` Chris Friesen
2016-06-20 22:43 ` Chris Friesen
2016-06-20 23:13 ` Chris Friesen
2016-06-21 9:07 ` Zdenek Kabelac
2016-06-21 15:22 ` Chris Friesen
2016-06-22 9:23 ` Zdenek Kabelac
2016-06-22 14:52 ` Chris Friesen
2016-06-23 8:34 ` Zdenek Kabelac
2016-06-23 16:35 ` Chris Friesen [this message]
2016-06-23 17:21 ` Zdenek Kabelac
2016-06-23 18:02 ` Chris Friesen
2016-06-24 11:00 ` Zdenek Kabelac
2016-07-01 6:51 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=576C0FEF.7060301@windriver.com \
--to=chris.friesen@windriver.com \
--cc=linux-lvm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.