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 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).