* failover speed
@ 2006-08-28 18:53 seth vidal
2006-08-29 16:57 ` seth vidal
2006-09-05 13:59 ` SCSI Sense patch bart brooks
0 siblings, 2 replies; 7+ messages in thread
From: seth vidal @ 2006-08-28 18:53 UTC (permalink / raw)
To: dm-devel
Hi,
I've gotten failover and failback working, however, I'm not sure if the
amount of wait time for the failover is reasonable. I'm using QLogic
2340 cards and an EVA8000. I'm curious if anyone else using something
similar is seeing in terms of failover times.
When things are running as I'd expect I'm seeing just a few seconds
before the new path is up. When things seem wrong it's waiting and
queueing for as much as 1.5 minutes.
What should I be expecting?
My multipath.conf looks like this:
defaults {
user_friendly_names yes
multipath_tool "/sbin/multipath -v0"
udev_dir /dev
polling_interval 10
default_selector "round-robin 0"
default_path_grouping_policy failover
default_getuid_callout "/sbin/scsi_id -g -u -s /block/%
n"
default_prio_callout "/bin/true"
default_features "0"
rr_min_io 100
failback immediate
}
devnode_blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^cciss!c[0-9]d[0-9]*"
}
multipaths {
multipath {
wwid
3600508b40010764b0000b00003630000
alias "lun1"
path_grouping_policy failover
path_checker readsector0
path_selector "round-robin 0"
failback 20
rr_weight priorities
no_path_retry queue
}
multipath {
wwid
3600508b40010764b0000b00003660000
alias "lun2"
path_grouping_policy failover
path_checker readsector0
path_selector "round-robin 0"
failback 20
rr_weight priorities
no_path_retry queue
}
multipath {
wwid
3600508b40010764b0000b000036b0000
alias "lun3"
path_grouping_policy failover
path_checker readsector0
path_selector "round-robin 0"
failback 20
rr_weight priorities
no_path_retry queue
}
multipath {
wwid
3600508b40010764b0000b000036e0000
alias "lun4"
path_grouping_policy failover
path_checker readsector0
path_selector "round-robin 0"
failback 20
rr_weight priorities
no_path_retry queue
}
}
devices {
device {
# vendor "HP "
# product "HSV210 "
vendor "HP*"
product "HSV210*"
path_grouping_policy group_by_prio
getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
path_checker tur
path_selector "round-robin 0"
prio_callout "/sbin/mpath_prio_alua %d"
failback immediate
no_path_retry 60
}
}
Thanks,
-sv
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: failover speed
2006-08-28 18:53 failover speed seth vidal
@ 2006-08-29 16:57 ` seth vidal
2006-09-05 13:59 ` SCSI Sense patch bart brooks
1 sibling, 0 replies; 7+ messages in thread
From: seth vidal @ 2006-08-29 16:57 UTC (permalink / raw)
To: device-mapper development
On Mon, 2006-08-28 at 14:53 -0400, seth vidal wrote:
> Hi,
> I've gotten failover and failback working, however, I'm not sure if the
> amount of wait time for the failover is reasonable. I'm using QLogic
> 2340 cards and an EVA8000. I'm curious if anyone else using something
> similar is seeing in terms of failover times.
>
> When things are running as I'd expect I'm seeing just a few seconds
> before the new path is up. When things seem wrong it's waiting and
> queueing for as much as 1.5 minutes.
>
Okay - I read #8 on the faq in the wiki which told me to look for \*tmo
\* files in /sys/
The problem is I'm running a 2.6.9 kernel for rhel4/centos4 and it
doesn't have those, yet.
I did, however, find these:
/sys/class/fc_transport/target1:0:0/device/1:0:0:*/timeout
which are set to 30s each.
Are these the functional equivalent of each other? Or if I set the above
down to say 6s or 3s will I encounter other types of suffering?
Thanks,
-sv
^ permalink raw reply [flat|nested] 7+ messages in thread
* SCSI Sense patch
2006-08-28 18:53 failover speed seth vidal
2006-08-29 16:57 ` seth vidal
@ 2006-09-05 13:59 ` bart brooks
2006-09-05 15:10 ` Alasdair G Kergon
1 sibling, 1 reply; 7+ messages in thread
From: bart brooks @ 2006-09-05 13:59 UTC (permalink / raw)
To: dm-devel
I have been using for sometime Axboes SCSI sense data patches, which make
available the sense data in the bio end_io path and the dm-mpaths
hw_handler. They work very nice.
When will the show up in RHEL 4, in update 5 or later?
Thanks
Bart Brooks
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: SCSI Sense patch
2006-09-05 13:59 ` SCSI Sense patch bart brooks
@ 2006-09-05 15:10 ` Alasdair G Kergon
2006-09-05 15:56 ` bart brooks
0 siblings, 1 reply; 7+ messages in thread
From: Alasdair G Kergon @ 2006-09-05 15:10 UTC (permalink / raw)
To: device-mapper development
On Tue, Sep 05, 2006 at 01:59:51PM +0000, bart brooks wrote:
> I have been using for sometime Axboe?s SCSI sense data patches, which make
> available the sense data in the bio end_io path and the dm-mpath?s
> hw_handler. They work very nice.
> When will the show up in RHEL 4, in update 5 or later?
Unfortunately not because (1) upstream has decided not to use them but
to work towards an alternative way of achieving the same goal; and
(2) the patches involve a change to an important data structure that
might cause pre-compiled modules unconnected with device-mapper to cause
corruption.
Alasdair
--
agk@redhat.com
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: SCSI Sense patch
2006-09-05 15:10 ` Alasdair G Kergon
@ 2006-09-05 15:56 ` bart brooks
2006-09-05 17:39 ` Mike Christie
0 siblings, 1 reply; 7+ messages in thread
From: bart brooks @ 2006-09-05 15:56 UTC (permalink / raw)
To: dm-devel
Hi Alasdair,
I take it you are referring to the addition of bi_error to the bio data
structure.
Any idea when an alternate solution will be available, is it still in the
discussion phase ?
Thanks
Bart Brooks
>From: Alasdair G Kergon <agk@redhat.com>
>Reply-To: device-mapper development <dm-devel@redhat.com>
>To: device-mapper development <dm-devel@redhat.com>
>Subject: Re: [dm-devel] SCSI Sense patch
>Date: Tue, 5 Sep 2006 16:10:05 +0100
>MIME-Version: 1.0
>Received: from hormel.redhat.com ([209.132.177.30]) by
>bay0-mc8-f11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Tue, 5
>Sep 2006 08:10:25 -0700
>Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com
>[10.8.4.110])by hormel.redhat.com (Postfix) with ESMTPid 54EFF73268; Tue,
>5 Sep 2006 11:10:25 -0400 (EDT)
>Received: from int-mx1.corp.redhat.com
>(int-mx1.corp.redhat.com[172.16.52.254])by listman.util.phx.redhat.com
>(8.13.1/8.13.1) with ESMTP idk85FAN1m020225 for
><dm-devel@listman.util.phx.redhat.com>;Tue, 5 Sep 2006 11:10:23 -0400
>Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com
>[172.16.10.17])by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with
>ESMTP idk85FA9vF015603for <dm-devel@int-mx1.corp.redhat.com>; Tue, 5 Sep
>2006 11:10:22 -0400
>Received: from agk.surrey.redhat.com (agk.surrey.redhat.com
>[172.16.10.74])by pobox.surrey.redhat.com (8.12.11.20060308/8.12.11) with
>ESMTP idk85FA5f6012975for <dm-devel@redhat.com>; Tue, 5 Sep 2006 16:10:05
>+0100
>Received: from agk by agk.surrey.redhat.com with local (Exim 4.34)id
>1GKcYv-0008IM-M2for dm-devel@redhat.com; Tue, 05 Sep 2006 16:10:05 +0100
>X-Message-Info: LsUYwwHHNt3660MmjhEvYg2f34OAemlKtU9j2Z7TuGo=
>Mail-Followup-To: device-mapper development <dm-devel@redhat.com>
>References:
><1156791189.26413.8.camel@cutter><BAY114-F20C6936AC3F7E04C0C7C429D300@phx.gbl>
>User-Agent: Mutt/1.4.1i
>X-loop: dm-devel@redhat.com
>X-BeenThere: dm-devel@redhat.com
>X-Mailman-Version: 2.1.5
>Precedence: junk
>List-Id: device-mapper development <dm-devel.redhat.com>
>List-Unsubscribe:
><https://www.redhat.com/mailman/listinfo/dm-devel>,<mailto:dm-devel-request@redhat.com?subject=unsubscribe>
>List-Archive: <https://www.redhat.com/archives/dm-devel>
>List-Post: <mailto:dm-devel@redhat.com>
>List-Help: <mailto:dm-devel-request@redhat.com?subject=help>
>List-Subscribe:
><https://www.redhat.com/mailman/listinfo/dm-devel>,<mailto:dm-devel-request@redhat.com?subject=subscribe>
>Errors-To: dm-devel-bounces@redhat.com
>Return-Path: dm-devel-bounces@redhat.com
>X-OriginalArrivalTime: 05 Sep 2006 15:10:25.0736 (UTC)
>FILETIME=[6A6B5480:01C6D0FD]
>
>On Tue, Sep 05, 2006 at 01:59:51PM +0000, bart brooks wrote:
> > I have been using for sometime Axboe?s SCSI sense data patches, which
>make
> > available the sense data in the bio end_io path and the dm-mpath?s
> > hw_handler. They work very nice.
> > When will the show up in RHEL 4, in update 5 or later?
>
>Unfortunately not because (1) upstream has decided not to use them but
>to work towards an alternative way of achieving the same goal; and
>(2) the patches involve a change to an important data structure that
>might cause pre-compiled modules unconnected with device-mapper to cause
>corruption.
>
>Alasdair
>--
>agk@redhat.com
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: SCSI Sense patch
2006-09-05 15:56 ` bart brooks
@ 2006-09-05 17:39 ` Mike Christie
2006-09-05 21:12 ` bart brooks
0 siblings, 1 reply; 7+ messages in thread
From: Mike Christie @ 2006-09-05 17:39 UTC (permalink / raw)
To: device-mapper development
bart brooks wrote:
> Hi Alasdair,
>
> I take it you are referring to the addition of “bi_error” to the bio
> data structure.
> Any idea when an alternate solution will be available, is it still in
> the discussion phase ?
>
I did two possible alternatives when trying to think of a way around
KABI. You can find them here
http://www.cs.wisc.edu/~michaelc/block/dm/rhel4/
I am not pushing either approach right now since one is a crazy ugly
hack (u3-bio-sense/) that I do not want to maintain or try to completely
test for something like RHEL. The other possibility (u3-blkerr) is nicer
but needs to be fixed up for some cases and needs lots of testing. The
latter approach is also a little hacky since I had to work around the
KABI restrictions but I do not think it is as evil as the u3-bio-sense
approach.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: SCSI Sense patch
2006-09-05 17:39 ` Mike Christie
@ 2006-09-05 21:12 ` bart brooks
0 siblings, 0 replies; 7+ messages in thread
From: bart brooks @ 2006-09-05 21:12 UTC (permalink / raw)
To: dm-devel
Hi Mike,
Thanks for responding to my question
I took a look at the patches and see what you mean.
It would be a nightmare to maintain error code mapping in the scsi-core for
each unique type of device that produces UA/sense data.
Bart
>From: Mike Christie <michaelc@cs.wisc.edu>
>Reply-To: device-mapper development <dm-devel@redhat.com>
>To: device-mapper development <dm-devel@redhat.com>
>Subject: Re: [dm-devel] SCSI Sense patch
>Date: Tue, 05 Sep 2006 12:39:26 -0500
>MIME-Version: 1.0
>Received: from hormel.redhat.com ([209.132.177.30]) by
>bay0-mc6-f16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Tue, 5
>Sep 2006 10:39:45 -0700
>Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com
>[10.8.4.110])by hormel.redhat.com (Postfix) with ESMTPid C936273117; Tue,
>5 Sep 2006 13:39:42 -0400 (EDT)
>Received: from int-mx1.corp.redhat.com
>(int-mx1.corp.redhat.com[172.16.52.254])by listman.util.phx.redhat.com
>(8.13.1/8.13.1) with ESMTP idk85HdfWF000464 for
><dm-devel@listman.util.phx.redhat.com>;Tue, 5 Sep 2006 13:39:41 -0400
>Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])by
>int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP
>idk85HdfiK029876for <dm-devel@redhat.com>; Tue, 5 Sep 2006 13:39:41 -0400
>Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20])by
>mx3.redhat.com (8.13.1/8.13.1) with ESMTP id k85HdWOT001383for
><dm-devel@redhat.com>; Tue, 5 Sep 2006 13:39:33 -0400
>Received: from [192.168.0.7] (CPE-70-92-133-61.mn.res.rr.com
>[70.92.133.61])(authenticated bits=0)by sabe.cs.wisc.edu (8.13.6/8.13.6)
>with ESMTP id k85HdVd6024654(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA
>bits=256 verify=NO)for <dm-devel@redhat.com>; Tue, 5 Sep 2006 12:39:32
>-0500
>X-Message-Info: LsUYwwHHNt3660MmjhEvYg2f34OAemlKtU9j2Z7TuGo=
>User-Agent: Thunderbird 1.5 (X11/20060313)
>References: <BAY114-F483ED5326C22601EF09069D300@phx.gbl>
>X-Enigmail-Version: 0.94.0.0
>X-RedHat-Spam-Score: 0 X-loop: dm-devel@redhat.com
>X-BeenThere: dm-devel@redhat.com
>X-Mailman-Version: 2.1.5
>Precedence: junk
>List-Id: device-mapper development <dm-devel.redhat.com>
>List-Unsubscribe:
><https://www.redhat.com/mailman/listinfo/dm-devel>,<mailto:dm-devel-request@redhat.com?subject=unsubscribe>
>List-Archive: <https://www.redhat.com/archives/dm-devel>
>List-Post: <mailto:dm-devel@redhat.com>
>List-Help: <mailto:dm-devel-request@redhat.com?subject=help>
>List-Subscribe:
><https://www.redhat.com/mailman/listinfo/dm-devel>,<mailto:dm-devel-request@redhat.com?subject=subscribe>
>Errors-To: dm-devel-bounces@redhat.com
>Return-Path: dm-devel-bounces@redhat.com
>X-OriginalArrivalTime: 05 Sep 2006 17:39:45.0634 (UTC)
>FILETIME=[46EF4420:01C6D112]
>
>bart brooks wrote:
> > Hi Alasdair,
> >
> > I take it you are referring to the addition of bi_error to the bio
> > data structure.
> > Any idea when an alternate solution will be available, is it still in
> > the discussion phase ?
> >
>
>I did two possible alternatives when trying to think of a way around
>KABI. You can find them here
>
>http://www.cs.wisc.edu/~michaelc/block/dm/rhel4/
>
>I am not pushing either approach right now since one is a crazy ugly
>hack (u3-bio-sense/) that I do not want to maintain or try to completely
>test for something like RHEL. The other possibility (u3-blkerr) is nicer
>but needs to be fixed up for some cases and needs lots of testing. The
>latter approach is also a little hacky since I had to work around the
>KABI restrictions but I do not think it is as evil as the u3-bio-sense
>approach.
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-09-05 21:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-28 18:53 failover speed seth vidal
2006-08-29 16:57 ` seth vidal
2006-09-05 13:59 ` SCSI Sense patch bart brooks
2006-09-05 15:10 ` Alasdair G Kergon
2006-09-05 15:56 ` bart brooks
2006-09-05 17:39 ` Mike Christie
2006-09-05 21:12 ` bart brooks
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.