All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 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?

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.