On 03/02/2013 11: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.
- multipathd, AFAIK, should start before any service that has it's data stored on the remote storage.
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.
And here lies the chicken-egg problem. At this point, only the root filesystem is mounted and
> it is mounted read-only. It is the correct and proper startup
sequence in Slackware. Filesystems
> are checked for errors after LVM starts and then root is
remounted read-write and the rest
> of the filesystems are mounted.
The problem is that multipathd wants to create a PID file under /var (which is at this time readonly).
> This fails and multipathd fails to start.
It took me a lot of testing and reboots until I managed to determine this is the actual problem.
Hmm. Why? multipathd can happily live without a PID file; SUSE has
been doing this for years (for precisely the same reason).
Check the SUSE init scripts.
The stop-gap solution I have found, so far, is to load dm-multipath module and run multipath -v0
before LVM, thus creating the multipath devices, then later, after the filesystems are remounted
> rw, start multipathd.
Bah.
Just start multipathd without creating a pid file.
Then you can check if multipathd runs via the multipathd CLI.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@xxxxxxx +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
