All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Varoqui <christophe.varoqui@free.fr>
To: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Cc: dm-devel@redhat.com, agk@redhat.com
Subject: Re: [RFC] How to fix system stall on root volume multipath
Date: Mon, 19 Nov 2007 01:17:41 +0100	[thread overview]
Message-ID: <1195431462.27535.43.camel@localhost.localdomain> (raw)
In-Reply-To: <1195202472.27535.27.camel@localhost.localdomain>


Le vendredi 16 novembre 2007 à 09:41 +0100, Christophe Varoqui a écrit :
> > > 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.
> > 
> I'm sorry I forgot to post the git-cached part of the changeset, i.e.
> libprio/ files.
> 
> There it goes.

Upstream git hosts the initial libprio/ commit.

I ported all useful prioritizers, leaving balance_units in the dark.
(If someone is actually using it, please say so)

This time, I cared for a bit of testing and the stuff seems to actually
work.

Now I'm interested in feedback from the Netapp fault injection team.
And any other feedback.

Regards,
cvaroqui
> 

  reply	other threads:[~2007-11-19  0:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-09 23:17 [RFC] How to fix system stall on root volume multipath Kiyoshi Ueda
2007-11-10  3:31 ` Alasdair G Kergon
2007-11-12 16:24   ` Kiyoshi Ueda
2007-11-13  1:01     ` Christophe Varoqui
2007-11-13 19:30       ` Kiyoshi Ueda
2007-11-13 22:02       ` Benjamin Marzinski
2007-11-16  8:41       ` Christophe Varoqui
2007-11-19  0:17         ` Christophe Varoqui [this message]
2007-12-20 18:10           ` Kiyoshi Ueda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1195431462.27535.43.camel@localhost.localdomain \
    --to=christophe.varoqui@free.fr \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=k-ueda@ct.jp.nec.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.