All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christophe Varoqui <christophe.varoqui@free.fr>
To: Alasdair G Kergon <agk@redhat.com>
Cc: device-mapper development <dm-devel@redhat.com>,
	linux-scsi@vger.kernel.org
Subject: Re: [dm-devel] Read-Only devices, multipath and more
Date: Tue, 20 May 2008 23:09:49 +0200	[thread overview]
Message-ID: <1211317789.31536.9.camel@plop> (raw)
In-Reply-To: <20080520144807.GC10723@agk.fab.redhat.com>

Le mardi 20 mai 2008 à 15:48 +0100, Alasdair G Kergon a écrit :
> On Fri, May 16, 2008 at 09:35:44PM +0200, christophe varoqui wrote:
> > fact: device-mapper refuse to load a RW multipath table on these paths
> > (ie without libdevmapper:set_task_set_ro())
> > question: should change this behaviour to allow to load a RW multipath
> > table on these paths and let the IO be failed by the storage hardware ?
> 
> Yes.  But relax this *only* for multipath targets, where the whole idea
> is to "hide" path problems from the layer above.

Fair enough.

> It would not make sense 
> in my view to do this for other DM targets.
>  

During my testing I remember seeing a RW linear map loaded over a RO
multipath map (through a genuine vgchange -ay, the PV being the
multipath).

> > Alasdair proposed to add more explicit table loading ioctl return code
> > when the failure is due to this ready-only paths issue (E_ROFS for
> > example).
> 
> I think this should be done too (for non-multipath and other errors).
> 
Right, I'm about the publish a changeset for supporting the whole RO
notion in the multipath-tools :
1/ printing the RO/RW information
2/ fallbacking to RO when RW loading fails
3/ new flag to force map reloading, which takes care of the RO->RW
promotion and RW->RO demotion scenarii

I'll adapt 2/ to your new return codes when available.


Thanks for caring,
cvaroqui

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2008-05-20 21:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-16 19:35 Read-Only devices, multipath and more Christophe Varoqui
2008-05-16 19:57 ` multipathd: error calling out mpath_prio_hds_modular Craig Simpson
2008-05-16 21:01   ` malahal
2008-05-16 23:19     ` Craig Simpson
2008-05-16 23:34       ` Craig Simpson
2008-05-17  0:17         ` malahal
2008-05-19 22:02         ` "[undef] [ready] [orphan]" ? Craig Simpson
2008-05-19 22:31           ` Craig Simpson
2008-05-20 14:48 ` [dm-devel] Read-Only devices, multipath and more Alasdair G Kergon
2008-05-20 21:09   ` Christophe Varoqui [this message]

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=1211317789.31536.9.camel@plop \
    --to=christophe.varoqui@free.fr \
    --cc=agk@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    /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.