All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergio Durigan Junior <sergio.durigan@canonical.com>
To: dm-devel@redhat.com
Subject: [dm-devel] Selectively start multipathd
Date: Sat, 16 Sep 2023 14:12:29 -0400	[thread overview]
Message-ID: <874jjuq96a.fsf@canonical.com> (raw)

Hello,

I have been working on this proof of concept to see if it's feasible to
start multipathd only on situations where there is actually a multipath
device present in the system.

The motivation behind this investigation is the fact that, in Ubuntu
(and Debian), we're always starting multipathd irrespective of whether
there's a multipath device to be acted upon.  This is OK when the user
needs the service, but can become problematic if we're dealing with
e.g. a limited-resource system like a Raspberry Pi.

My initial (and somewhat naïve) plan was to use systemd and do something
like ConditionPathExistsGlob to check if there's an "mpathX" device
present, but obviously this is not possible because the device name can
be easily changed.

I'm now thinking whether it is possible to implement some udev rule for
that.  Maybe extend the existing 60-multipath.rules file, even though it
seems to be executed when the device is not yet ready (as is suggested
by the "ENV{SYSTEMD_READY}=0" sections).

My multipath-fu is lacking a bit as can be seen above, so I would really
appreciate some expert advice/opinion here.  I tried finding related
discussions in the mailing list but couldn't see anything promising
there.

Thank you,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel

                 reply	other threads:[~2023-09-16 18:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=874jjuq96a.fsf@canonical.com \
    --to=sergio.durigan@canonical.com \
    --cc=dm-devel@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.