Re: bio-based DM multipath is back from the dead [was: Re: Notes from the four separate IO track sessions at LSF/MM]

On Fri, May 27 2016 at 11:42am -0400, Hannes Reinecke wrote: > On 05/27/2016 04:44 PM, Mike Snitzer wrote: > >On Fri, May 27 2016 at 4:39am -0400, > >Hannes Reinecke wrote: > > > [ .. ] > >>No, the real issue is load-balancing. > >>If you have several paths you have

Re: bio-based DM multipath is back from the dead [was: Re: Notes from the four separate IO track sessions at LSF/MM]

On 05/27/2016 04:44 PM, Mike Snitzer wrote: On Fri, May 27 2016 at 4:39am -0400, Hannes Reinecke wrote: [ .. ] No, the real issue is load-balancing. If you have several paths you have to schedule I/O across all paths, _and_ you should be feeding these paths efficiently.

Re: bio-based DM multipath is back from the dead [was: Re: Notes from the four separate IO track sessions at LSF/MM]

On Fri, May 27 2016 at 4:39am -0400, Hannes Reinecke wrote: > On 05/26/2016 04:38 AM, Mike Snitzer wrote: > >On Thu, Apr 28 2016 at 11:40am -0400, > >James Bottomley wrote: > > > >>On Thu, 2016-04-28 at 08:11 -0400, Mike Snitzer wrote: >

Re: bio-based DM multipath is back from the dead [was: Re: Notes from the four separate IO track sessions at LSF/MM]

On 05/26/2016 04:38 AM, Mike Snitzer wrote: On Thu, Apr 28 2016 at 11:40am -0400, James Bottomley wrote: On Thu, 2016-04-28 at 08:11 -0400, Mike Snitzer wrote: Full disclosure: I'll be looking at reinstating bio-based DM multipath to regain efficiencies

bio-based DM multipath is back from the dead [was: Re: Notes from the four separate IO track sessions at LSF/MM]

On Thu, Apr 28 2016 at 11:40am -0400, James Bottomley wrote: > On Thu, 2016-04-28 at 08:11 -0400, Mike Snitzer wrote: > > Full disclosure: I'll be looking at reinstating bio-based DM multipath to > > regain efficiencies that now really matter when issuing

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

r.kernel.org>, "Mike Snitzer" <snit...@redhat.com>, linux-bl...@vger.kernel.org, "device-mapper development" <dm-de...@redhat.com>, l...@lists.linux-foundation.org Sent: Monday, May 2, 2016 6:28:16 PM Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessi

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 inflight requiring error handling serially. This means we will still have to wait to get a path failover until all are through the

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

uot;James Bottomley" <james.bottom...@hansenpartnership.com>, "linux-scsi" > <linux-scsi@vger.kernel.org>, "Mike Snitzer" <snit...@redhat.com>, > linux-bl...@vger.kernel.org, "device-mapper development" > <dm-de...@redhat.com>, l

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

vger.kernel.org>, "Mike Snitzer" <snit...@redhat.com>, linux-bl...@vger.kernel.org, "device-mapper development" <dm-de...@redhat.com>, l...@lists.linux-foundation.org Sent: Friday, April 29, 2016 8:36:22 PM Subject: Re: [dm-devel] [Lsf] Notes from the four s

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

nux-scsi@vger.kernel.org>, "Mike Snitzer" <snit...@redhat.com>, linux-bl...@vger.kernel.org, "device-mapper development" <dm-de...@redhat.com>, l...@lists.linux-foundation.org Sent: Friday, April 29, 2016 8:36:22 PM Subject: Re: [dm-devel] [Lsf] Notes fro

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 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

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

uot; <dm-de...@redhat.com>, l...@lists.linux-foundation.org, "Benjamin Marzinski" <bmarz...@redhat.com> Sent: Friday, April 29, 2016 5:47:07 PM Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM Hello Bart I will email the entire log just to

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

ley" <james.bottom...@hansenpartnership.com>, "device-mapper development" <dm-de...@redhat.com>, l...@lists.linux-foundation.org Sent: Thursday, April 28, 2016 12:47:24 PM Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM Hello Bart, This

Re: [dm-devel] Notes from the four separate IO track sessions at LSF/MM

On Wed, Apr 27, 2016 at 04:39:49PM -0700, James Bottomley wrote: > Multipath - Mike Snitzer > > > Mike began with a request for feedback, which quickly lead to the > complaint that recovery time (and how you recover) was one of the > biggest issues in device mapper

Re: [Lsf] Notes from the four separate IO track sessions at LSF/MM

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

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

t;james.bottom...@hansenpartnership.com>, "device-mapper development" <dm-de...@redhat.com>, l...@lists.linux-foundation.org Sent: Thursday, April 28, 2016 12:41:26 PM Subject: Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM On 04/28/2016 09:23 A

Re: [dm-devel] [Lsf] Notes from the four separate IO track sessions at LSF/MM

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

Re: [Lsf] Notes from the four separate IO track sessions at LSF/MM

28, 2016 11:54 AM > 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

Re: [Lsf] Notes from the four separate IO track sessions at LSF/MM

r" <snit...@redhat.com> Cc: linux-bl...@vger.kernel.org, l...@lists.linux-foundation.org, "device-mapper development" <dm-de...@redhat.com>, "linux-scsi" <linux-scsi@vger.kernel.org> Sent: Thursday, April 28, 2016 11:53:50 AM Subject: Re: [Lsf] Notes from the fo

RE: [Lsf] Notes from the four separate IO track sessions at LSF/MM

y; 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, users and i

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 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

Re: Notes from the four separate IO track sessions at LSF/MM

On Thu, 2016-04-28 at 08:11 -0400, Mike Snitzer wrote: > On Wed, Apr 27 2016 at 7:39pm -0400, > James Bottomley wrote: > > > Multipath - Mike Snitzer > > > > > > Mike began with a request for feedback, which quickly lead to the >

Re: Notes from the four separate IO track sessions at LSF/MM

On Wed, Apr 27 2016 at 7:39pm -0400, James Bottomley wrote: > Multipath - Mike Snitzer > > > Mike began with a request for feedback, which quickly lead to the > complaint that recovery time (and how you recover) was one of the >

Notes from the four separate IO track sessions at LSF/MM

This year, we only had two scribes from LWN.net, not three, so there won't be any coverage of the IO track when we split into three tracks. To cover for that, here are my notes of the four separated sessions === Multiqueue Interrupt and Queue Assignment; Hannes Reinecke