From: "Bryn M. Reeves" <bmr@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: "Andrei B." <andrixnet@yahoo.com>
Subject: Re: Chicken and egg problem with multipath-tools
Date: Mon, 04 Mar 2013 10:54:15 +0000 [thread overview]
Message-ID: <51347D57.9000908@redhat.com> (raw)
In-Reply-To: <1362220999.44153.YahooMailClassic@web126202.mail.ne1.yahoo.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/02/2013 10:43 AM, Andrei B. wrote:
> Hi,
>
> I've been trying to install multipath-tools on a couple of linux
> servers with FC storage that I work with. They run Linux
> Slackware. I've built from source, created an installable package
> (Slackware style) and deployed it.
>
> I have discovered the following problem (chicken and egg style):
>
> - multipathd, AFAIK, should start before LVM, because if several
> volumes need be assembled by LVM, they should exist before LVM
> starts.
The daemon is not required to discovery paths; just call "multipath"
in the initramfs or early userspace to create mapped devices. Start
the daemon later when you have writable root/var (or hack around it as
I mentioned in my other reply).
> - multipathd, AFAIK, should start before any service that has it's
> data stored on the remote storage.
No need usually. There is a small window where a path failure during
boot will not be recoverable however in over five years supporting
distros using this approach I've never seen that happen in practice
(the timing is tight - it must be after mapping the device but before
userspace gets going and it must require the daemon to intervene to
reinstate paths to carry on).
> I am not familiar [enough] with the inner workings of the startup
> sequence on redhat/debian like systems. Slackware's startup
> sequence is much simpler and I placed multipathd in file rc.S
> (which is the first one called by init) right before LVM.
Call multipath instead. Then start multipathd after your LVM devices
are up and /var is writable.
Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlE0fVcACgkQ6YSQoMYUY96cnQCeI/AYeKvu36kpdefUeLT4mNvw
1ycAoNQlgCK2D+fyHOjrEsPilzWMz+sn
=qWjC
-----END PGP SIGNATURE-----
prev parent reply other threads:[~2013-03-04 10:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-02 10:43 Chicken and egg problem with multipath-tools Andrei B.
2013-03-03 11:42 ` Gabriel de Perthuis
2013-03-03 21:01 ` Andrei B
2013-03-04 10:49 ` Bryn M. Reeves
2013-03-04 6:54 ` Hannes Reinecke
2013-03-04 11:00 ` Andrei B.
2013-03-04 11:13 ` Hannes Reinecke
2013-03-04 11:27 ` Bryn M. Reeves
2013-03-04 10:54 ` Bryn M. Reeves [this message]
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=51347D57.9000908@redhat.com \
--to=bmr@redhat.com \
--cc=andrixnet@yahoo.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.