On 6/8/21 4:26 PM, Martin Wilck wrote:
On Mo, 2021-06-07 at 16:30 -0500, David Teigland wrote:
On Mon, Jun 07, 2021 at 10:27:20AM +, Martin Wilck wrote:
Most importantly, this was about LVM2 scanning of physical volumes.
The
number of udev workers has very little influence on PV scanning,
b
On Di, 2021-06-08 at 11:03 -0500, David Teigland wrote:
> On Tue, Jun 08, 2021 at 03:47:39PM +, Martin Wilck wrote:
> > Hm. You can boot with "multipath=off" which udev would take into
> > account. What would you do in that case? Native mpath detection
> > would
> > probably not figure it out.
On Di, 2021-06-08 at 15:56 +0200, Peter Rajnoha wrote:
>
> The issue is that we're relying now on udev db records that contain
> info about mpath and MD components - without this, the detection (and
> hence filtering) could fail in certain cases. So if go without
> checking
> udev db, that'll be a
On Di, 2021-06-08 at 17:19 +0200, Peter Rajnoha wrote:
> On Tue 08 Jun 2021 14:48, Martin Wilck wrote:
> >
> > Recent multipath-tools ships the "libmpathvalid" library that
> > could be used for this purpose, to make the logic comply with what
> > multipathd itself uses. It could be used as an alt
On Di, 2021-06-08 at 18:02 +0200, Zdenek Kabelac wrote:
> >
> > > A third related improvement that could follow is to add stronger
> > > native
> > > mpath detection, in which lvm uses uses /etc/multipath/wwids,
> > > directly or
> > > through a multipath library, to identify mpath components. Th
On Di, 2021-06-08 at 10:39 -0500, David Teigland wrote:
>
> . Use both native md/mpath detection *and* udev info when it's
> readily
> available (don't wait for it), instead of limiting ourselves to one
> source of info. If either source indicates an md/mpath component,
> then we consider i
On 6/8/21 5:30 AM, David Teigland wrote:
On Mon, Jun 07, 2021 at 10:27:20AM +, Martin Wilck wrote:
Most importantly, this was about LVM2 scanning of physical volumes. The
number of udev workers has very little influence on PV scanning,
because the udev rules only activate systemd service. Th
On Di, 2021-06-08 at 14:29 +0200, Peter Rajnoha wrote:
> On Mon 07 Jun 2021 16:48, David Teigland wrote:
> >
> > If there are say 1000 PVs already present on the system, there
> > could be
> > real savings in having one lvm command process all 1000, and then
> > switch
> > over to processing ueven
On Mo, 2021-06-07 at 16:30 -0500, David Teigland wrote:
> On Mon, Jun 07, 2021 at 10:27:20AM +, Martin Wilck wrote:
> > Most importantly, this was about LVM2 scanning of physical volumes.
> > The
> > number of udev workers has very little influence on PV scanning,
> > because the udev rules onl
On Tue, Jun 08, 2021 at 03:47:39PM +, Martin Wilck wrote:
> Hm. You can boot with "multipath=off" which udev would take into
> account. What would you do in that case? Native mpath detection would
> probably not figure it out.
libmpathvalid will still know?
> Please don't. Use libmpathvalid i
Dne 08. 06. 21 v 17:47 Martin Wilck napsal(a):
On Di, 2021-06-08 at 10:39 -0500, David Teigland wrote:
. Use both native md/mpath detection *and* udev info when it's
readily
available (don't wait for it), instead of limiting ourselves to one
source of info. If either source indicates an m
On Tue, Jun 08, 2021 at 08:26:01AM +, Martin Wilck wrote:
> IIUC, 2) is the effect of _pvscan_aa_quick(). 3) is surprising;
> apparently libudev's device detection causes a factor 3 slowdown.
> While 40s is not bad, you can see that event based activation still
> performs far worse than "serial
On Tue 08 Jun 2021 14:48, Martin Wilck wrote:
> On Di, 2021-06-08 at 15:56 +0200, Peter Rajnoha wrote:
> >
> > The issue is that we're relying now on udev db records that contain
> > info about mpath and MD components - without this, the detection (and
> > hence filtering) could fail in certain ca
Dne 08. 06. 21 v 15:56 Peter Rajnoha napsal(a):
On Tue 08 Jun 2021 15:46, Zdenek Kabelac wrote:
Dne 08. 06. 21 v 15:41 Peter Rajnoha napsal(a):
On Tue 08 Jun 2021 13:23, Martin Wilck wrote:
On Di, 2021-06-08 at 14:29 +0200, Peter Rajnoha wrote:
On Mon 07 Jun 2021 16:48, David Teigland wrote:
On Tue 08 Jun 2021 15:46, Zdenek Kabelac wrote:
> Dne 08. 06. 21 v 15:41 Peter Rajnoha napsal(a):
> > On Tue 08 Jun 2021 13:23, Martin Wilck wrote:
> > > On Di, 2021-06-08 at 14:29 +0200, Peter Rajnoha wrote:
> > > > On Mon 07 Jun 2021 16:48, David Teigland wrote:
> > > > > If there are say 1000 PV
Dne 08. 06. 21 v 15:41 Peter Rajnoha napsal(a):
On Tue 08 Jun 2021 13:23, Martin Wilck wrote:
On Di, 2021-06-08 at 14:29 +0200, Peter Rajnoha wrote:
On Mon 07 Jun 2021 16:48, David Teigland wrote:
If there are say 1000 PVs already present on the system, there
could be
real savings in having on
On Tue 08 Jun 2021 13:23, Martin Wilck wrote:
> On Di, 2021-06-08 at 14:29 +0200, Peter Rajnoha wrote:
> > On Mon 07 Jun 2021 16:48, David Teigland wrote:
> > >
> > > If there are say 1000 PVs already present on the system, there
> > > could be
> > > real savings in having one lvm command process
On Mon 07 Jun 2021 16:48, David Teigland wrote:
> On Mon, Jun 07, 2021 at 03:48:30PM +, Martin Wilck wrote:
> > On So, 2021-06-06 at 14:15 +0800, heming.z...@suse.com wrote:
> > >
> > > 1. During boot phase, lvm2 automatically swithes to direct activation
> > > mode
> > > ("event_activation =
On Mo, 2021-06-07 at 23:30 +0800, heming.z...@suse.com wrote:
> On 6/7/21 6:27 PM, Martin Wilck wrote:
> > On So, 2021-06-06 at 11:35 -0500, Roger Heflin wrote:
> > > This might be a simpler way to control the number of threads at
> > > the
> > > same time.
> > >
> > > On large machines (cpu wise,
On So, 2021-06-06 at 11:35 -0500, Roger Heflin wrote:
> This might be a simpler way to control the number of threads at the
> same time.
>
> On large machines (cpu wise, memory wise and disk wise). I have
> only seen lvm timeout when udev_children is set to default. The
> default seems to be s
On So, 2021-06-06 at 14:15 +0800, heming.z...@suse.com wrote:
>
> 1. During boot phase, lvm2 automatically swithes to direct activation
> mode
> ("event_activation = 0"). After booted, switch back to the event
> activation mode.
>
> Booting phase is a speical stage. *During boot*, we could "prete
21 matches
Mail list logo
