Re: [linux-lvm] Discussion: performance issue on event activation mode

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/