linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: LVM general discussion and development <linux-lvm@redhat.com>,
	Julian Andres Klode <julian.klode@canonical.com>
Subject: Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules
Date: Wed, 31 Jul 2019 12:16:37 +0200	[thread overview]
Message-ID: <dd20d3cf-36a8-167c-a46b-3f06bf27e079@redhat.com> (raw)
In-Reply-To: <20190731093328.ily6u3xgpbnovyen@jak-t480s>

Dne 31. 07. 19 v 11:33 Julian Andres Klode napsal(a):
> On Wed, Jul 31, 2019 at 11:21:10AM +0200, Zdenek Kabelac wrote:
>>> Debian and Ubuntu, as Debian requires support for non-systemd inits, and
>>> Ubuntu requires event-based root device finding in initramfs. Surely that's
> 
> This is nonsense. No Ubuntu release has systemd-based background scanning,
> and all of them work fine. Also, it's still possible to not use backgrounding
> by building lvm2 accordingly - so much for "not working".

lvm2 activation cannot be time-bounded by random udev-rule timeout
(being chosen by systemd/udev developers anywhere between 90-180seconds).

The fact it 'mostly' works is because majority of activations are finished
with this time constrain, but it doesn't make it 'a workable' solution.

So as long as there is 'randomly' killing udev timeout - we can't relocate
activation back into udev rule.

> In our current development series, we did merge the new change to enable
> the background handling from Debian, and this caused our initramfs to fail.

Sorry to say this, we are aware of several other non-upstream accepted 
'workarounds' within Debian lvm2 packages - I can only wish users affected 
with problems caused by these 'hacks' would be asking for repair and recovery 
scenarios only and directly their authors...

> Hence, this approach to revert to the previous behavior where needed (as it
> was clearly working), and still use systemd if available.

When it appears to work on a system with a single disk really doesn't make it 
'clearly working' - we are providing solution for thousands disks based 
heavily loaded servers as well, so there is not much wish to 'hack-in' 
occasionally working fix.

So some other proposal the offloads activation out of udev rule is needed.


Regards

Zdenek

  reply	other threads:[~2019-07-31 10:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 18:49 Julian Andres Klode
2019-07-30 15:02 ` Zdenek Kabelac
2019-07-30 15:12   ` Julian Andres Klode
2019-07-31  9:21     ` Zdenek Kabelac
2019-07-31  9:33       ` Julian Andres Klode
2019-07-31 10:16         ` Zdenek Kabelac [this message]
2019-07-31 10:51           ` Gionatan Danti
2019-07-31 11:12             ` Zdenek Kabelac
2019-07-31  9:39       ` Julian Andres Klode
2019-07-31 10:22         ` Zdenek Kabelac
2019-07-31 10:41           ` Julian Andres Klode
2019-07-31 11:09             ` 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=dd20d3cf-36a8-167c-a46b-3f06bf27e079@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=julian.klode@canonical.com \
    --cc=linux-lvm@redhat.com \
    --subject='Re: [linux-lvm] [PATCH] Detect systemd at run-time in 69-dm-lvm-metad.rules' \
    /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

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).