linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Chris Friesen <chris.friesen@windriver.com>
To: linux-lvm@redhat.com
Subject: Re: [linux-lvm] what creates the symlinks in /dev/<volgroup> ?
Date: Tue, 21 Jun 2016 09:22:44 -0600	[thread overview]
Message-ID: <57695BC4.3040205@windriver.com> (raw)
In-Reply-To: <4094fb9b-01d7-8358-8a91-fa65719af0e4@redhat.com>

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?

Personally, I think that running that command should use the same logic as the 
udev rules to decide whether or not to create a symlink, and should create the 
symlink pointing to the same place as the udev rules.

I'm not sure what you're talking about as far as duplicates, I'm not seeing any 
duplicate devices.  The problem I see is that "vgscan --mknodes" or "vgmknodes" 
will both create an additional symlink when compared to the udev rules, and the 
additional symlink is not deleted when I deactivate the volume group.

For what it's worth, in my lvm.conf I have "use_lvmetad = 0" and

global_filter = [ "a|/dev/sda|", "a|/dev/drbd4|",  "a|/dev/sda6|", "r|.*|" ]

Chris


On 06/21/2016 03:07 AM, Zdenek Kabelac wrote:
> Dne 21.6.2016 v 01:13 Chris Friesen napsal(a):
>> It appears that "vgscan --mknodes" also creates this symlink, and creates it
>> pointing to /dev/mapper/<name> instead of to /dev/dm-X like udev does.
>>
>> controller-1:/dev# vgscan -v --mknodes
>>     Wiping cache of LVM-capable devices
>>     Wiping internal VG cache
>>   Reading all physical volumes.  This may take a while...
>>     Using volume group(s) on command line.
>>   Found volume group "nova-local" using metadata type lvm2
>>   Found volume group "cgts-vg" using metadata type lvm2
>>   Found volume group "cinder-volumes" using metadata type lvm2
>>     Using logical volume(s) on command line.
>>   The link /dev/cinder-volumes/cinder-volumes-pool should have been created by
>> udev but it was not found. Falling back to direct link creation.
>>
>> controller-1:/dev# ls -l /dev/cinder-volumes/
>> total 0
>> lrwxrwxrwx 1 root root  7 Jun 20 22:43 anchor-lv -> ../dm-9
>> lrwxrwxrwx 1 root root 49 Jun 20 23:09 cinder-volumes-pool ->
>> /dev/mapper/cinder--volumes-cinder--volumes--pool
>>
>>
>> This is a bad thing, because running the above or "vgmknodes" and then running
>> "vgchange -an cinder-volumes" will leave the /dev/cinder-volumes directory
>> with a dangling symlink in it.
>>
>> This in turn breaks /usr/lib/ocf/resource.d/heartbeat/LVM, which (perhaps
>> erroneously) uses the existence of a non-empty /dev/<volume_group> directory
>> as a test to see if the volume group is active or not.
>>
>
>
> This whole thread is presentint  one continues sets of bugs and misunderstandings.
>
>
> On modern Linux system - it should be ONLY udev to create any links in /dev dir.
> So  lvm2 does not create ANY links unless forced to do.
>
> So the clear answer here is   'it is udev rule that creates links'
>
>
> Now the second part - you system is likely misconfigured.
> It's admin responsibility to filter out devices in a way lvm2 does not get any
> duplicates.  If the same device (same UUID) is seen multiple times,
> lvm2 has no way to know which of them is the right one to use.
>
> Since you have not even shown the version of lvm2 in use and whather lvmetad is
> in use - there is no way to give you any more hints...
>
> Regards
>
> Zdenek
>
> _______________________________________________
> 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/

  reply	other threads:[~2016-06-21 15:22 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 [this message]
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
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=57695BC4.3040205@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).