From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: sekharan@linux.vnet.ibm.com
Cc: device-mapper development <dm-devel@redhat.com>,
SCSI development list <linux-scsi@vger.kernel.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Mike Christie <mchristi@redhat.com>,
Edward Goggin <egoggin@vmware.com>,
"Benoit, Arthur" <Benoit_Arthur@emc.com>,
asson_ronald <asson_ronald@emc.com>,
berthiaume_wayne <berthiaume_wayne@emc.com>
Subject: Re: [dm-devel] mechanism for multipath to pass information to hardware handler
Date: Fri, 26 Jun 2009 14:55:54 -0500 [thread overview]
Message-ID: <1246046154.3925.80.camel@mulgrave.site> (raw)
In-Reply-To: <1246045509.14164.33.camel@chandra-ubuntu>
On Fri, 2009-06-26 at 12:45 -0700, Chandra Seetharaman wrote:
> Yes, Mike Christie and I were aware of this and it was one of the issue
> we were trying to resolve before we pushed scsi_dh interface upstream.
> (It is little complicated as we need the parameters to be set per
> vendor-product tuple).
>
> The original code I ported to scsi_dh interface was from Ed Goggin(who
> was working for EMC then). IIRC, he was also aware of this issue.
>
> When we pushed scsi_dh interface, we did get few of the EMC folks (on
> Cc) to review/test the code and they did, and this issue was not seen as
> a problem.
>
> We wanted to get back to that issue sometime later, got busy with other
> things, and it disappeared from my list of things-to-do as the
> regression was not seen as an issue (till now :)... I will get back to
> it.
One way around this might simply be to make the device_handlers create a
sysfs interface for additional parameters. Then the multipath command
can feed them (or in a pinch, users relying on the features can pass
them in manually). Right at the moment having no possible work around
does appear to be an issue.
James
next prev parent reply other threads:[~2009-06-26 19:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-24 17:14 mechanism for multipath to pass information to hardware handler Eddie Williams
2009-06-26 19:10 ` [dm-devel] " James Bottomley
2009-06-26 19:45 ` Chandra Seetharaman
2009-06-26 19:55 ` James Bottomley [this message]
2009-06-27 0:03 ` Chandra Seetharaman
2009-06-27 17:48 ` Mike Christie
2009-06-26 20:01 ` [dm-devel] " Eddie Williams
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=1246046154.3925.80.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=Benoit_Arthur@emc.com \
--cc=asson_ronald@emc.com \
--cc=berthiaume_wayne@emc.com \
--cc=dm-devel@redhat.com \
--cc=egoggin@vmware.com \
--cc=linux-scsi@vger.kernel.org \
--cc=mchristi@redhat.com \
--cc=rjw@sisk.pl \
--cc=sekharan@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox