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

Ritesh Raj Sarraf rrs at researchut.com
Mon Jun 25 14:07:20 UTC 2012

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.

We care to create the proper multipath maps in the initrd.

> I can also imagine setups with a multipath SAN with LVM that and each LV
> having a different multipath setup. E.g. LV1 uses path1 with fallback to
> path2 and LV2 the other way around.
Which would be asking for trouble for all your LVs are are served of a VG
that resides on multiple maps. Your VG will hang/error out when only one of
the maps go down.

> Please let me know if you are expecting something else from multipath.
> 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.

> 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.

>         Goswin

Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20120625/7f82c30d/attachment.html>

More information about the pkg-lvm-maintainers mailing list