From: Chandra Seetharaman <sekharan@us.ibm.com>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: linux-scsi@vger.kernel.org,
device-mapper development <dm-devel@redhat.com>,
andmike@us.ibm.com, asson_ronald@emc.com,
James.Bottomley@HansenPartnership.com, Benoit_Arthur@emc.com,
jens.axboe@oracle.com, agk@redhat.com, berthiaume_wayne@emc.com
Subject: Re: [dm-devel] [PATCH 4/7] scsi_dh: add EMC Clariion device handler
Date: Tue, 22 Apr 2008 16:45:53 -0700 [thread overview]
Message-ID: <1208907953.1025.235.camel@chandra-ubuntu> (raw)
In-Reply-To: <480E5D08.3000905@cs.wisc.edu>
On Tue, 2008-04-22 at 16:47 -0500, Mike Christie wrote:
<snip>
> > wait
> > ******************************************************
> > Simple Run:
> >
> > with patchset: 2.6.25-mm1:
> > real 3m30.122s real 3m29.746s
> > user 0m4.069s user 0m4.099s
> > sys 0m14.876s sys 0m14.535s
> > -----------------------------------------------
>
> Is this just a boot up test or a test just running IO but no
> failback/failover?
Test running IO but no failover/failback.
>
> >
> > Failover Run:
> >
> > with patchset: 2.6.25-mm1:
> > real 5m18.875s real 5m31.741s
> > user 0m4.069s user 0m3.883s
> > sys 0m14.838s sys 0m13.822s
>
> Ehh, I have no idea if this is good or bad. Does it mean it is talking
> 13 more seconds to complete?
It is taking 13 more seconds without the serialization :) (i.e the old
code).
>
> Have you seen the type of thread on dm-devel or the iscsi list where
> people are concerned with getting the time the failure is detected to
> the time IO is running on a new path down from something like 10 to 5
I totally agree with you that shaving a second here and a second there
has lot of value to the customers.
>
> seconds. One time the iscsi driver did not implement time2wait correctly
> and by fixing it we shaved only 2 seconds off and users were very happy
> with the extra 2 seconds. We added the nop timer stuff so we could get
> faster failovers. We have the fast io fail tmo so we can speed up the
> process even more. Shaving off a second here or there is really nitpicky
> and if I were you I would give me the middle finger :) It just seems
But, I wouldn't :)
>
> like people expect better performance from this type of error.
>
> If my comment is too nitpicky then I am fine with ignoring this for now.
> We just have to fix the emc short/long tress pass code then. I added
> another EMC guy to the thread so he can ping the other EMC devs to get
> going (I had sent them questions on how to handle it and have not got a
> response).
next prev parent reply other threads:[~2008-04-22 23:45 UTC|newest]
Thread overview: 15+ 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
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 ` Chandra Seetharaman [this message]
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
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=1208907953.1025.235.camel@chandra-ubuntu \
--to=sekharan@us.ibm.com \
--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=berthiaume_wayne@emc.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=michaelc@cs.wisc.edu \
/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.