Re: [dm-devel] multipathd.init

[Igor Feoktistov <igorf netapp com>]

Does it have to be running from initrd in case of root on dm-multipath?
Would not it be sufficient just run multipath from initrd and then run
multipathd from init scripts? This is exactly what I'm doing in the lab
so far...

>From: Alasdair G Kergon <agk redhat com>
>To: device-mapper development <dm-devel redhat com>
>Mail-Followup-To: device-mapper development <dm-devel redhat com>
>Content-Disposition: inline
>User-Agent: Mutt/1.4.1i
>X-loop: dm-devel redhat com
>Subject: [dm-devel] multipathd.init
>
>Attached is a cleaned-up version of multipathd init script - at least 
>for Red Hat based systems.
>
>While it uses the standard daemon-handling functions, it's still only 
>suitable for a few situations though.
>
>If you have / on dm-multipath, the daemon has to be started from
>the initrd - so you don't want it stopping/starting from init.d,
>but you might want to HUP it.
>
>If you have other system parts of your filesystem (e.g. /usr) you 
>want the daemon starting from rc.sysinit.
>
>If you have data filesystems over multipath, you want something
>to mount them after multipathd starts.
>
>And you might also have cryptsetup, md, lvm2, kpartx involved
>- in various combinations...
>
>So you could have a multi-level startup with multiple instances
>of multipathd each configured to manage only a subset of devices.
>Then the init.d multipathd script would only kill the daemon
>instance started during by the init.d script, and would leave
>alone the instances managing / and /usr.
>
>Or you could forget completely about init.d and /var/lock/subsys
>and /var/run and just launch the daemon from the initrd or
>failing that from rc.sysinit.
>
>Then you would need a new mechanism to manage it.
>(ie a dedicated client program that communicates with it e.g. via
>shared memory)
>I anticipate that something like this is the right way to go.
>
>That client program could even be 'dmsetup' if the daemon functionality
>could be incorporated into plug-ins: The various types of mirroring 
>have similar requirements, so it's sensible to have a single
>daemon infrastructure for them all.
>
>Alasdair
>-- 
>agk redhat com