From: Mike Christie <michaelc@cs.wisc.edu>
To: device-mapper development <dm-devel@redhat.com>
Cc: andmike@us.ibm.com, linux-scsi@vger.kernel.org,
asson_ronald@emc.com, James.Bottomley@HansenPartnership.com,
Benoit_Arthur@emc.com, jens.axboe@oracle.com, agk@redhat.com
Subject: Re: [PATCH 4/7] scsi_dh: add EMC Clariion device handler
Date: Wed, 16 Apr 2008 11:29:00 -0500 [thread overview]
Message-ID: <4806294C.9090703@cs.wisc.edu> (raw)
In-Reply-To: <20080416011842.19580.92056.sendpatchset@chandra-ubuntu>
Chandra Seetharaman wrote:
> +
> +static int send_cmd(struct scsi_device *sdev, int cmd)
> +{
> + struct request *rq = get_req(sdev, cmd);
> +
> + if (!rq)
> + return SCSI_DH_RES_TEMP_UNAVAIL;
> +
> + return blk_execute_rq(sdev->request_queue, NULL, rq, 1);
> +}
> +
My only concerns are:
1. EMC and HP need to send a command to every device to transition them.
Because we do blk_execute_rq from the dm multipath workqueue we can now
only failover/failback for a couple devices at a time.
I am not sure if this is a big deal, because this the error handler path
so it is going to be slower than the normal path. But it seems like
customers are really picky about failover times and want them as fast as
possible. If they have a couple hundred devices doing a couple at a time
might be something that users see as a regression from the old code. I
am not sure though. I just do not want the bugzillas when they come to
work :)
2. EMC guys did you test the short vs long tress pass stuff? Do we need
to add some code to handle the case where we send a short one, but we
needed to send a long one. Is there some sense error or some inquiry
data we can base this off of?
next prev parent reply other threads:[~2008-04-16 16:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-16 1:18 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 1/7] scsi_dh: add skeleton for SCSI Device Handlers Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 2/7] scsi_dh: add lsi rdac device handler Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 3/7] scsi_dh: add hp sw " Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 4/7] scsi_dh: add EMC Clariion " Chandra Seetharaman
2008-04-16 16:29 ` Mike Christie [this message]
2008-04-16 23:59 ` [dm-devel] " Chandra Seetharaman
2008-04-17 17:14 ` Mike Christie
2008-04-22 21:09 ` [dm-devel] " Chandra Seetharaman
2008-04-22 21:47 ` Mike Christie
2008-04-22 21:50 ` Mike Christie
2008-04-22 23:45 ` [dm-devel] " Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 5/7] scsi_dh: Use SCSI device handler in dm-multipath Chandra Seetharaman
2008-04-16 1:18 ` [PATCH 6/7] scsi_dh: Remove hardware handlers from dm Chandra Seetharaman
2008-04-16 1:19 ` [PATCH 7/7] scsi_dh: Remove hardware handler infrastructure " Chandra Seetharaman
-- strict thread matches above, loose matches on Subject: below --
2008-04-17 22:22 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-17 22:23 ` [PATCH 4/7] scsi_dh: add EMC Clariion device handler Chandra Seetharaman
2008-04-17 21:18 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-17 21:19 ` [PATCH 4/7] scsi_dh: add EMC Clariion device handler Chandra Seetharaman
2008-04-01 22:51 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-04-01 22:51 ` [PATCH 4/7] scsi_dh: add EMC Clariion device handler Chandra Seetharaman
2008-03-11 1:33 [PATCH 0/7] scsi_dh: Move hardware handlers from dm to SCSI Chandra Seetharaman
2008-03-11 1:33 ` [PATCH 4/7] scsi_dh: add EMC Clariion device handler Chandra Seetharaman
2008-02-28 1:08 [PATCH 0/7] Move hardware handlers from dm layer to SCSI layer Chandra Seetharaman
2008-02-28 1:08 ` [PATCH 4/7] scsi_dh: add EMC Clariion device handler Chandra Seetharaman
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=4806294C.9090703@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=Benoit_Arthur@emc.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=agk@redhat.com \
--cc=andmike@us.ibm.com \
--cc=asson_ronald@emc.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).