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

From: Benjamin Marzinski <bmarzins@redhat.com>
To: David Teigland <teigland@redhat.com>
Cc: "zkabelac@redhat.com" <zkabelac@redhat.com>,
	Heming Zhao <heming.zhao@suse.com>,
	"prajnoha@redhat.com" <prajnoha@redhat.com>,
	"linux-lvm@redhat.com" <linux-lvm@redhat.com>,
	Martin Wilck <martin.wilck@suse.com>
Subject: Re: [linux-lvm] Discussion: performance issue on event activation mode
Date: Tue, 28 Sep 2021 13:03:21 -0500	[thread overview]
Message-ID: <20210928180321.GG3087@octiron.msp.redhat.com> (raw)
In-Reply-To: <20210928155609.GE11549@redhat.com>

On Tue, Sep 28, 2021 at 10:56:09AM -0500, David Teigland wrote:
> 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.

If you don't need the device to pivot to the real filesystem and LVM,
MD, etc. don't activate those devices in the initramfs, you don't need
to include the multipath module when building the initramfs in dracut.
Many existing setups with multipath already work this way. The problem
we need to solve is the setups that DO need the multipath device to
exist before other devices get stacked on top or filesystems get
mounted in the initramfs.

-Ben

> 
> 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/