Bug#678693: Please add a /usr/share/initramfs-tools/scripts/local-block/ script

Goswin von Brederlow goswin-v-b at web.de
Tue Jun 26 08:56:01 UTC 2012

Ritesh Raj Sarraf <rrs at researchut.com> writes:

> Hello Goswin,
> On Mon, Jun 25, 2012 at 6:50 PM, Goswin von Brederlow <goswin-v-b at web.de>
> wrote:
>     Ritesh Raj Sarraf <rrs at researchut.com> writes:
>     > Do you see this affecting multipath?
>     >
>     > There is no use case to run dm-multipath on a local block device.
>     Don't be too sure about that. I've been playing with dm-multipath on
>     local block devices because it has a timeout feature. If a single device
>     in a raid hangs (which can take up to several minutes till all the
>     resets on all levels have been tried before you get an error or may
>     actualy hang forever) you can use multipath to make it give up faster.
> I am still curious why you would want to run multipath on top of a local device
> ?
> You definitely want device mapper but multipath IMO.
> As for USB deivces, multipath highly recommends blacklisting local (which
> includes USB) devices.
>     > There are setups where you would want LVM on top of your SAN Multipath
>     > Device, but I think we already take care of that.
>     Since multipath-tools doesn't provide any initramfs-tools scripts yet
>     I don't see how that could be. I think booting from a multipath device
>     isn't supported at all yet, right?
> It does. http://anonscm.debian.org/gitweb/?p=pkg-lvm/multipath-tools.git;a=
> tree;f=debian/initramfs;h=79f50dfee645e2dc72268a306099285bf0dc0b33;hb=HEAD
> We care to create the proper multipath maps in the initrd.

Ah, sorry, those files end up in multipath-tools-boot. I only checked
the multipath-tools deb itself.

>     One of the problems in current initramfs-tools is with devices that take
>     a long time to be detected. My experience with external enclosures was
>     that detecting the drives takes rather long, just like USB takes it
>     time.
> Yes. The remote SAN devices have timing issues. And we try best to handle that
> situation. I still think that is not the use case you have.
> And if you have issues with a remote SAN device setup, please do report it.

That is exactly the issue the patch addresses. In your multipath
local-top script you have:

verbose && log_begin_msg "Loading multipath modules"
for module in ${MP_MODULES}; do
  if modprobe "$module"; then
    verbose && log_success_msg "loaded module ${module}."
    log_failure_msg "failed to load module ${module}."
verbose && log_end_msg

verbose && log_begin_msg "Discovering multipaths"
/sbin/multipath -v $VERBOSITY
verbose && log_end_msg

if [ -x /sbin/kpartx -a -x /sbin/dmsetup ]; then
    /sbin/dmsetup ls --target multipath --exec "/sbin/kpartx -a -p -part" >/dev/null

Where do you handle the situation that a device takes longer to apear?
By the time that script runs the remote device might not yet have
appeared and then multipath can't setup its part.

Note that the problem isn't the multipath devices not appearing on time
but the underlying devices you want to multipath taking too long. There
is nothing multipath can do to make them appear, their detection is
generally asynchronous.

As an example we have some external raid enclosures here that take over
3 minutes to boot. So after a power loss the servers always boot without
the enclosures and minutes later they show up all of a sudden and only
then can configure their multipath. Luckily we boot from local disks so
that isn't as big a problem.

If we had to boot from multipath then we would need to set
rootdelay=200, causing every boot to just wait for 3 minutes, even on
warm reboots where that is totaly unnecessary. The initramfs patch I
made allows to wait until the devices appear. If that happens in 1s then
the boot continues after 1s.

>     So I think that if you add support to boot from multipath then it would
>     definetly fall under the problem cases and need a local-block script
>     rather than local-top.
> Boot from multipath (i.e. Root on multipath) is a setup we support. It is
> documented in the README.Debian file.
>     MfG
>            Goswin
> Thanks,
> Ritesh


More information about the pkg-lvm-maintainers mailing list