Thks Mike, that explains it :)
On Mar 16, 5:27 pm, Mike Christie wrote:
> On 03/16/2010 04:02 PM, bennyturns wrote:
>
> > I am trying work out a formula for total failover time of my
> > multipathed iSCSI device so far I have:
>
> > failover time = nop timout + nop interval + replacement_timeout
On 03/16/2010 04:02 PM, bennyturns wrote:
I am trying work out a formula for total failover time of my
multipathed iSCSI device so far I have:
failover time = nop timout + nop interval + replacement_timeout
seconds + scsi block device timeout(/sys/block/sdX/device/timeout)
/sys/block/sdX/devi
I am trying work out a formula for total failover time of my
multipathed iSCSI device so far I have:
failover time = nop timout + nop interval + replacement_timeout
seconds + scsi block device timeout(/sys/block/sdX/device/timeout)
Is there anything else that I am missing?
-b
On Mar 15, 4:53
On 03/16/2010 04:50 AM, Alex Zeffertt wrote:
Mike Christie wrote:
On 03/15/2010 05:56 AM, Alex Zeffertt wrote:
The bugzilla ticket requests a merge of two git commits, but neither of
those contain the libiscsi.c change that addresses bug #2. Was this a
mistake, or did you deliberately omit that
Mike Christie wrote:
On 03/15/2010 05:56 AM, Alex Zeffertt wrote:
The bugzilla ticket requests a merge of two git commits, but neither of
those contain the libiscsi.c change that addresses bug #2. Was this a
mistake, or did you deliberately omit that part of your
speed-up-conn-fail-take3.patch w
On 03/15/2010 05:56 AM, Alex Zeffertt wrote:
The bugzilla ticket requests a merge of two git commits, but neither of
those contain the libiscsi.c change that addresses bug #2. Was this a
mistake, or did you deliberately omit that part of your
speed-up-conn-fail-take3.patch when you raised the ti
Mike Christie wrote:
On 03/07/2010 07:46 AM, Pasi Kärkkäinen wrote:
On Fri, Mar 05, 2010 at 05:07:53AM -0600, Mike Christie wrote:
On 03/01/2010 08:53 PM, Mike Christie wrote:
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It shou
On Mon, Mar 08, 2010 at 02:07:14PM -0600, Mike Christie wrote:
> On 03/07/2010 07:46 AM, Pasi Kärkkäinen wrote:
>> On Fri, Mar 05, 2010 at 05:07:53AM -0600, Mike Christie wrote:
>>> On 03/01/2010 08:53 PM, Mike Christie wrote:
On 03/01/2010 12:06 PM, bet wrote:
> 1. Based on my timeouts I
On 03/07/2010 07:46 AM, Pasi Kärkkäinen wrote:
On Fri, Mar 05, 2010 at 05:07:53AM -0600, Mike Christie wrote:
On 03/01/2010 08:53 PM, Mike Christie wrote:
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It should timeout about 15 s
On Fri, Mar 05, 2010 at 05:07:53AM -0600, Mike Christie wrote:
> On 03/01/2010 08:53 PM, Mike Christie wrote:
>> On 03/01/2010 12:06 PM, bet wrote:
>>> 1. Based on my timeouts I would think that my session would time out
>>
>> Yes. It should timeout about 15 secs after you see
>> > Mar 1 07:14:27
On 03/01/2010 08:53 PM, Mike Christie wrote:
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It should timeout about 15 secs after you see
> Mar 1 07:14:27 bentCluster-1 kernel: connection4:0: ping timeout of
> 5 secs expired, recv
I was able to get my failover time down to about 25-30 seconds:
Mar 1 12:32:37 bentCluster-1 kernel: tg3: eth0: Link is down.
Mar 1 12:33:03 bentCluster-1 multipathd: checker failed path 8:224 in
map mpath0
Mar 1 12:33:03 bentCluster-1 kernel: end_request: I/O error, dev sdo,
sector 1249431
Ma
Mike Christie wrote:
> You might be hitting a bug where the network layer gets stuck trying to
> send data. I attached a patch that should fix the problem
Doing some multipath testing with iscsi/tcp I didn't hit this bug, any hint
what does it take to have this come into play? I did failover on s
Mike Christie wrote:
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It should timeout about 15 secs after you see
> Mar 1 07:14:27 bentCluster-1 kernel: connection4:0: ping timeout of
> 5 secs expired, recv timeout 5, last rx 4
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It should timeout about 15 secs after you see
> Mar 1 07:14:27 bentCluster-1 kernel: connection4:0: ping timeout of
> 5 secs expired, recv timeout 5, last rx 4884304, last ping 488930
Hi all. I am going through some testing of my multipathed iSCSI
devices and I am seeing some longer than expected delays. I am
running the latest RHEL 5.4 packages as of this morning. I am seeing
the failure of the iSCSI sessions take about 67 seconds. After the
iSCSI failure the multipath laye
16 matches
Mail list logo
