From: David Teigland <teigland@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: "bmarzins@redhat.com" <bmarzins@redhat.com>,
"zkabelac@redhat.com" <zkabelac@redhat.com>,
"prajnoha@redhat.com" <prajnoha@redhat.com>,
"linux-lvm@redhat.com" <linux-lvm@redhat.com>,
Heming Zhao <heming.zhao@suse.com>
Subject: Re: [linux-lvm] Discussion: performance issue on event activation mode
Date: Tue, 28 Sep 2021 10:56:09 -0500 [thread overview]
Message-ID: <20210928155609.GE11549@redhat.com> (raw)
In-Reply-To: <138b7ddb721b6a58df8f0401b76c7975678f0dda.camel@suse.com>
On Tue, Sep 28, 2021 at 03:16:08PM +0000, Martin Wilck wrote:
> Hm. This would mean that the switch to event-based PV detection could
> happen before "udev settle" ends. A coldplug storm of uevents could
> create 1000s of PVs in a blink after event-based detection was enabled.
> Wouldn't that resurrect the performance issues that you are trying to
> fix with this patch set?
Possibly, I'm unsure how this looks in practice, so I need to try it.
When the device node exists will make a difference, not only when the
uevent occurs.
> > Otherwise, when the devices file is not used,
> > md: from reading the md headers from the disk
> > mpath: from reading sysfs links and /etc/multipath/wwids
>
> Ugh. Reading sysfs links means that you're indirectly depending on
> udev, because udev creates those. It's *more* fragile than calling into
> libudev directly, IMO.
I meant /sys/dev/block/... (some of those files are links).
We don't look at /dev symlinks created by udev.
> Using /etc/multipath/wwids is plain wrong in
> general. It works only on distros that use "find_multipaths strict",
> like RHEL. Not to mention that the path can be customized in
> multipath.conf.
Right, it's not great and I held off for a couple years adding that.
As a practical matter it can at least help. There's a constant stream
of problems with mpath component detection, so anything that can help I'm
interested in. I expect we could be more intelligent understanding
multipath config to handle more cases.
> multipathd does listen to uevents (only "udev" events, not "kernel").
> But that doesn't help us on startup. Currently we try hard to start up
> after coldplug is finished. multipathd doesn't have a concurrency issue
> like LVM2 (at least I hope so; it handles events with just two threads,
> a producer and a consumer). The problem is rather that dm devices
> survive the initramfs->rootfs switch, while member devices don't (see
> above).
The other day I suggested that multipath devices not be set up in
the initramfs at all. If the root fs requires mpath, then handle that
as a special one-off setup. Then the transition problems go away.
But, I know basically nothing about this, so I won't be surprised if
there are reasons it's done this way.
Dave
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
next prev parent reply other threads:[~2021-09-28 15:56 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-06 6:15 [linux-lvm] Discussion: performance issue on event activation mode heming.zhao
2021-06-06 16:35 ` Roger Heflin
2021-06-07 10:27 ` Martin Wilck
2021-06-07 15:30 ` heming.zhao
2021-06-07 15:45 ` Martin Wilck
2021-06-07 20:52 ` Roger Heflin
2021-06-07 21:30 ` David Teigland
2021-06-08 8:26 ` Martin Wilck
2021-06-08 15:39 ` David Teigland
2021-06-08 15:47 ` Martin Wilck
2021-06-08 16:02 ` Zdenek Kabelac
2021-06-08 16:05 ` Martin Wilck
2021-06-08 16:03 ` David Teigland
2021-06-08 16:07 ` Martin Wilck
2021-06-15 17:03 ` David Teigland
2021-06-15 18:21 ` Zdenek Kabelac
2021-06-16 16:18 ` heming.zhao
2021-06-16 16:38 ` David Teigland
2021-06-17 3:46 ` heming.zhao
2021-06-17 15:27 ` David Teigland
2021-06-08 16:49 ` heming.zhao
2021-06-08 16:18 ` heming.zhao
2021-06-09 4:01 ` heming.zhao
2021-06-09 5:37 ` Heming Zhao
2021-06-09 18:59 ` David Teigland
2021-06-10 17:23 ` heming.zhao
2021-06-07 15:48 ` Martin Wilck
2021-06-07 16:31 ` Zdenek Kabelac
2021-06-07 21:48 ` David Teigland
2021-06-08 12:29 ` Peter Rajnoha
2021-06-08 13:23 ` Martin Wilck
2021-06-08 13:41 ` Peter Rajnoha
2021-06-08 13:46 ` Zdenek Kabelac
2021-06-08 13:56 ` Peter Rajnoha
2021-06-08 14:23 ` Zdenek Kabelac
2021-06-08 14:48 ` Martin Wilck
2021-06-08 15:19 ` Peter Rajnoha
2021-06-08 15:39 ` Martin Wilck
2021-09-09 19:44 ` David Teigland
2021-09-10 17:38 ` Martin Wilck
2021-09-12 16:51 ` heming.zhao
2021-09-27 10:00 ` Peter Rajnoha
2021-09-27 15:38 ` David Teigland
2021-09-28 6:34 ` Martin Wilck
2021-09-28 14:42 ` David Teigland
2021-09-28 15:16 ` Martin Wilck
2021-09-28 15:31 ` Martin Wilck
2021-09-28 15:56 ` David Teigland [this message]
2021-09-28 18:03 ` Benjamin Marzinski
2021-09-28 17:42 ` Benjamin Marzinski
2021-09-28 19:15 ` [dm-devel] " Martin Wilck
2021-09-28 19:15 ` Martin Wilck
2021-09-29 22:06 ` Peter Rajnoha
2021-09-30 7:51 ` Martin Wilck
2021-09-30 8:07 ` heming.zhao
2021-09-30 9:31 ` Martin Wilck
2021-09-30 11:41 ` Peter Rajnoha
2021-09-30 15:32 ` heming.zhao
2021-10-01 7:41 ` Martin Wilck
2021-10-01 8:08 ` Peter Rajnoha
2021-09-30 11:29 ` Peter Rajnoha
2021-09-30 16:04 ` David Teigland
2021-09-30 14:41 ` Benjamin Marzinski
2021-10-01 7:42 ` Martin Wilck
2021-09-29 21:53 ` Peter Rajnoha
2021-09-30 7:45 ` Martin Wilck
2021-09-29 21:39 ` Peter Rajnoha
2021-09-30 7:22 ` Martin Wilck
2021-09-30 14:26 ` David Teigland
2021-09-30 15:55 ` David Teigland
2021-10-01 8:00 ` Peter Rajnoha
2021-10-18 6:24 ` Martin Wilck
2021-10-18 15:04 ` David Teigland
2021-10-18 16:56 ` heming.zhao
2021-10-18 21:51 ` Zdenek Kabelac
2021-10-19 17:18 ` David Teigland
2021-10-20 14:40 ` Martin Wilck
2021-10-20 14:50 ` David Teigland
2021-10-20 14:54 ` Martin Wilck
2021-10-20 15:12 ` David Teigland
2021-06-07 16:40 ` David Teigland
2021-07-02 21:09 ` David Teigland
2021-07-02 21:22 ` Martin Wilck
2021-07-02 22:02 ` David Teigland
2021-07-03 11:49 ` heming.zhao
2021-07-08 10:10 ` Tom Yan
2021-07-02 21:31 ` Tom Yan
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=20210928155609.GE11549@redhat.com \
--to=teigland@redhat.com \
--cc=bmarzins@redhat.com \
--cc=heming.zhao@suse.com \
--cc=linux-lvm@redhat.com \
--cc=martin.wilck@suse.com \
--cc=prajnoha@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 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.