linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Chris Friesen <chris.friesen@windriver.com>
To: Zdenek Kabelac <zkabelac@redhat.com>,
	LVM general discussion and development <linux-lvm@redhat.com>
Subject: Re: [linux-lvm] what creates the symlinks in /dev/<volgroup> ?
Date: Wed, 22 Jun 2016 08:52:04 -0600	[thread overview]
Message-ID: <576AA614.6050800@windriver.com> (raw)
In-Reply-To: <8771709a-3ab2-e485-ce87-5a6c51e8a9a9@redhat.com>

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?


>> 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|.*|" ]
>
> And now we are getting to the point on your problem:
>
> "a|/dev/sda|"   will also match "a|/dev/sda6|"
> (and /dev/sda5...)
>
> If you would like to get only 'exact' '/dev/sda' you would need to use
>
> ^/dev/sda$
>
> otherwise '/dev/sda' may appear anywhere as substring of your device path.


Yes, the "/dev/sda" is intentional since we have multiple /dev/sda* devices that 
form part of various separate volume groups.  Really it's the /dev/sda6 that is 
extra here since it's already matched.

The problematic issue I'm seeing with udev/vgscan is actually with the volume 
group on /dev/drbd4.

I really don't think I'm having any problems with duplicates...just with vgscan 
creating extra symlinks compared to udev, that udev doesn't clean up.

Chris

  reply	other threads:[~2016-06-22 14:52 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 [this message]
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=576AA614.6050800@windriver.com \
    --to=chris.friesen@windriver.com \
    --cc=linux-lvm@redhat.com \
    --cc=zkabelac@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).