Monday, May 2, 2016 6:28:16 PM
Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at
LSF/MM
On 05/02/2016 12:28 PM, Laurence Oberman wrote:
> Even in the case of the ib_srp, don't we also have to still run the
> eh_timeout for each of the devices that has infligh
On 05/02/2016 12:28 PM, Laurence Oberman wrote:
Even in the case of the ib_srp, don't we also have to still run the
eh_timeout for each of the devices that has inflight requiring error
handling serially. This means we will still have to wait to get a
path failover until all are through the timeou
ottomley"
, "device-mapper development"
, l...@lists.linux-foundation.org
Sent: Monday, May 2, 2016 2:49:54 PM
Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at
LSF/MM
On 04/29/2016 05:47 PM, Laurence Oberman wrote:
> From: "Bart Van Assche"
&g
undation.org
Sent: Friday, April 29, 2016 8:36:22 PM
Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at
LSF/MM
On 04/29/2016 02:47 PM, Laurence Oberman wrote:
Recovery with 21 LUNS is 300s that have in-flights to abort.
[ ... ]
eh_deadline is set to 10 on the 2 qlogic
linux-foundation.org
Sent: Friday, April 29, 2016 8:36:22 PM
Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at
LSF/MM
On 04/29/2016 02:47 PM, Laurence Oberman wrote:
> Recovery with 21 LUNS is 300s that have in-flights to abort.
> [ ... ]
> eh_deadline i
On 04/29/2016 02:47 PM, Laurence Oberman wrote:
Recovery with 21 LUNS is 300s that have in-flights to abort.
[ ... ]
eh_deadline is set to 10 on the 2 qlogic ports, eh_timeout is set
> to 10 for all devices. In multipath fast_io_fail_tmo=5
I jam one of the target array ports and discard the co
"
To: "Bart Van Assche"
Cc: linux-bl...@vger.kernel.org, "linux-scsi" ,
"Mike Snitzer" , "James Bottomley"
, "device-mapper development"
, l...@lists.linux-foundation.org, "Benjamin Marzinski"
Sent: Friday, April 29, 2016 5:47:07 P
n
Principal Software Maintenance Engineer
Red Hat Global Support Services
- Original Message -
From: "Laurence Oberman"
To: "Bart Van Assche"
Cc: linux-bl...@vger.kernel.org, "linux-scsi" ,
"Mike Snitzer" , "James Bottomley"
, "device-ma
On Thu, 2016-04-28 at 16:19 +, Knight, Frederick wrote:
> There are multiple possible situations being intermixed in this
> discussion. First, I assume you're talking only about random access
> devices (if you try transport level error recover on a sequential
> access device - tape or SMR disk
: "Bart Van Assche"
To: "Laurence Oberman"
Cc: linux-bl...@vger.kernel.org, "linux-scsi" ,
"Mike Snitzer" , "James Bottomley"
, "device-mapper development"
, l...@lists.linux-foundation.org
Sent: Thursday, April 28, 2016 12:41:26 PM
Subject
On 04/28/2016 09:23 AM, Laurence Oberman wrote:
We still suffer from periodic complaints in our large customer base
> regarding the long recovery times for dm-multipath.
Most of the time this is when we have something like a switch
> back-plane issue or an issue where RSCN'S are blocked coming
; To: James Bottomley; Mike Snitzer
> Cc: linux-bl...@vger.kernel.org; l...@lists.linux-foundation.org;
> device-mapper development; linux-scsi
> Subject: Re: [Lsf] Notes from the four separate IO track sessions at LSF/MM
>
> On 04/28/2016 08:40 AM, James Bottomley wrote:
>> Well, the
device-mapper development" , "linux-scsi"
Sent: Thursday, April 28, 2016 11:53:50 AM
Subject: Re: [Lsf] Notes from the four separate IO track sessions at LSF/MM
On 04/28/2016 08:40 AM, James Bottomley wrote:
> Well, the entire room, that's vendors, users and implementors
tomley; Mike Snitzer
Cc: linux-bl...@vger.kernel.org; l...@lists.linux-foundation.org; device-mapper
development; linux-scsi
Subject: Re: [Lsf] Notes from the four separate IO track sessions at LSF/MM
On 04/28/2016 08:40 AM, James Bottomley wrote:
> Well, the entire room, that's vendors, u
On 04/28/2016 08:40 AM, James Bottomley wrote:
Well, the entire room, that's vendors, users and implementors
complained that path failover takes far too long. I think in their
minds this is enough substance to go on.
The only complaints I heard about path failover taking too long came
from pe
15 matches
Mail list logo
