[dm-devel] [RFC] How to fix system stall on root volume multipath

[Kiyoshi Ueda]

Hi Christophe,

On Tue, 13 Nov 2007 02:01:24 +0100, Christophe Varoqui <christophe.varoqui at free.fr> wrote:
> Le lundi 12 novembre 2007  11:24 -0500, Kiyoshi Ueda a crit :
> > Hi Alasdair,
> > 
> > On Sat, 10 Nov 2007 03:31:13 +0000, Alasdair G Kergon <agk at redhat.com> wrote:
> > > On Fri, Nov 09, 2007 at 06:17:19PM -0500, Kiyoshi Ueda wrote:
> > > > If we use multipath for "/", temporal all-paths failure could lead to
> > > > system stall because multipathd depends on callout programs on "/".
> > > > I would like to hear your comments about my idea to fix it.
> > >  
> > > I thought it avoided that problem by pre-loading everything into a ramdisk:
> > > did that code get dropped for some reason?
> > 
> > Thank you for the information!  I had forgotten it!
> > Yes, we used to have it, and it seems to be removed by the commit below:
> >     http://git.kernel.org/gitweb.cgi?p=linux/storage/multipath-tools/.git;a=commitdiff;h=cad20ecf8919b2126ab6f4f793a1a738e9864f59
> > 
> > And probably the following thread is related to the commit.
> >     https://www.redhat.com/archives/dm-devel/2005-July/msg00044.html
> > 
> > 
> > Ben, Christophe,
> > Is that code still problem for current multipathd?
> > And what do you think about my proposal?
>
> I'm not found of yet-another user-visible ramfs for multipathd use,
> that's why I started with the private namespace tricks. The problems are
> still there, and will stay till we stop using pthreads.
> 
> That may happen someday, as one of the main reason for pthread was the
> (blocking ioctl) libdevmapper event collection. And this is being
> superseded by path status uevents.
> 
> But not soon enough, and the private namespace stuff suffers from lack
> of friendliness anyway : we can't expect users to grasp easily that
> changing their prioritizer in /sbin won't be seen by the multipath
> daemon till restart, for example.
> 
> So I propose to start playing with your prioritizers-as-lib idea to see
> if it's practical.
> 
> I prepared the following patch to that effect. It is not complete
> (actually segfaults, no useful prioritizer ported) but can start fixing
> bugs and go where ever your personnal interest leads.

Thank you for the patch.
OK, I'll try the implementation.

Thanks,
Kiyoshi Ueda