Re: Recent kernels fail to boot on POWER8 with multipath SCSI

On Fri, Mar 30 2018 at 5:04P -0400, Michael Ellerman <mich...@ellerman.id.au> wrote: > Hi Mike, > > Paul's AFK so I tried the patch you sent. > > Mike Snitzer <snit...@redhat.com> writes: > > On Thu, Mar 29 2018 at 4:39am -0400, > > Paul Mackerras <p

Re: Recent kernels fail to boot on POWER8 with multipath SCSI

On Thu, Mar 29 2018 at 4:39am -0400, Paul Mackerras wrote: > Since commit 8d47e65948dd ("dm mpath: remove unnecessary NVMe > branching in favor of scsi_dh checks", 2018-03-05), upstream kernels > fail to boot on my POWER8 box which has multipath SCSI disks. The > host

Re: ERROR: "scsi_device_from_queue" [drivers/md/dm-multipath.ko] undefined!

On Sat, Mar 10 2018 at 2:29pm -0500, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 3266b5bd97eaa72793df0b6e5a106c69ccc166c4 > commit: 8d47e65948ddea4398892946d9e50778a316b397 dm mpath: remove

Re: [PATCH V3 1/8] scsi: hpsa: fix selection of reply queue

s Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike > > Snitzer; > > linux-scsi@vger.kernel.org; Hannes Reinecke; Arun Easi; Omar Sandoval; > > Martin K . Petersen; James Bottomley; Christoph Hellwig; Kashyap Desai; > > Peter > > Rivera; Meelis Roos > &

Re: [PATCH v5] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Tue, Jan 30 2018 at 9:44P -0500, Jens Axboe <ax...@kernel.dk> wrote: > On 1/30/18 7:24 AM, Mike Snitzer wrote: > > From: Ming Lei <ming@redhat.com> > > > > This status is returned from driver to block layer if device related > > resource is unavai

[PATCH v6] blk-mq: introduce BLK_STS_DEV_RESOURCE

_queue() will cover the above two cases and make sure IO hang can be avoided. One invariant is that queue will be rerun if SCHED_RESTART is set. Suggested-by: Jens Axboe <ax...@kernel.dk> Tested-by: Laurence Oberman <lober...@redhat.com> Signed-off-by: Ming Lei <ming@redhat.com

Re: [PATCH v5] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Tue, Jan 30 2018 at 2:42pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Tue, 2018-01-30 at 14:33 -0500, Mike Snitzer wrote: > > On Tue, Jan 30 2018 at 12:52pm -0500, > > Bart Van Assche <bart.vanass...@wdc.com> wrote: > > > > > -

Re: [PATCH v5] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Tue, Jan 30 2018 at 12:52pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On 01/30/18 06:24, Mike Snitzer wrote: > >+ * > >+ * If driver returns BLK_STS_RESOURCE and SCHED_RESTART > >+ * bit is set, run queue after

[PATCH v5] blk-mq: introduce BLK_STS_DEV_RESOURCE

_queue() will cover the above two cases and make sure IO hang can be avoided. One invariant is that queue will be rerun if SCHED_RESTART is set. Suggested-by: Jens Axboe <ax...@kernel.dk> Tested-by: Laurence Oberman <lober...@redhat.com> Signed-off-by: Ming Lei <ming@redhat.com

Re: [PATCH V4] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Mon, Jan 29 2018 at 4:51pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Mon, 2018-01-29 at 16:44 -0500, Mike Snitzer wrote: > > But regardless of which wins the race, the queue will have been run. > > Which is all we care about right? > > Running

Re: [PATCH V4] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Mon, Jan 29 2018 at 4:22pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Mon, 2018-01-29 at 15:33 -0500, Mike Snitzer wrote: > > +* If driver returns BLK_STS_RESOURCE and SCHED_RESTART > > +* bit is set, run queue after 10

Re: [LSF/MM TOPIC] Two blk-mq related topics

On Mon, Jan 29 2018 at 10:46am -0500, Ming Lei wrote: > 2. When to enable SCSI_MQ at default again? > > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In V4.13-rc1, > it is enabled at default, but later the patch is reverted in V4.13-rc7, and > becomes

[PATCH V4] blk-mq: introduce BLK_STS_DEV_RESOURCE

erman <lober...@redhat.com> Signed-off-by: Ming Lei <ming@redhat.com> Signed-off-by: Mike Snitzer <snit...@redhat.com> --- V4: - cleanup header and code comments - rerun queue after BLK_MQ_QUEUE_DELAY (3ms) instead of 10ms - eliminate nvmefc's queue re

Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Sat, Jan 27 2018 at 10:00pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Sat, 2018-01-27 at 21:03 -0500, Mike Snitzer wrote: > > You cannot even be forthcoming about the technical merit of a change you > > authored (commit 6077c2d70) that I'm left to

Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Sat, Jan 27 2018 at 7:54pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Sat, 2018-01-27 at 19:23 -0500, Mike Snitzer wrote: > > Your contributions do _not_ make up for your inability to work well with > > others. Tiresome doesn't begin to descri

Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Sat, Jan 27 2018 at 5:12pm -0500, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Sat, 2018-01-27 at 14:09 -0500, Mike Snitzer wrote: > > Ming let me know that he successfully tested this V3 patch using both > > your test (fio to both mpath and underlying pa

Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

On Tue, Jan 23 2018 at 10:31pm -0500, Ming Lei wrote: > On Tue, Jan 23, 2018 at 04:57:34PM +, Bart Van Assche wrote: > > On Wed, 2018-01-24 at 00:37 +0800, Ming Lei wrote: > > > On Tue, Jan 23, 2018 at 04:24:20PM +, Bart Van Assche wrote: > > > > My opinion about

Re: [PATCH V3] blk-mq: introduce BLK_STS_DEV_RESOURCE

ber...@redhat.com> > Cc: Christoph Hellwig <h...@infradead.org> > Cc: Mike Snitzer <snit...@redhat.com> > Cc: Laurence Oberman <lober...@redhat.com> > Cc: Bart Van Assche <bart.vanass...@sandisk.com> > Cc: Martin K. Petersen <martin.peter...@oracle.com> > C

Re: blk-mq: introduce BLK_STS_DEV_RESOURCE

On Sat, Jan 20 2018 at 7:57pm -0500, Ming Lei <ming@redhat.com> wrote: > On Sat, Jan 20, 2018 at 12:30:02PM -0500, Mike Snitzer wrote: > > On Sat, Jan 20 2018 at 8:48am -0500, > > Ming Lei <ming@redhat.com> wrote: > > > > > This status is ret

Re: blk-mq: introduce BLK_STS_DEV_RESOURCE

; This patch converts some drivers to use this return value. Meantime > if driver returns BLK_STS_RESOURCE and S_SCHED_RESTART is marked, run > queue after 10ms for avoiding IO hang. > > Suggested-by: Jens Axboe <ax...@kernel.dk> > Cc: Mike Snitzer <snit...@redhat.com> &

Re: [PATCH 23/27] drbd: make intelligent use of blkdev_issue_zeroout

On Mon, Jan 15 2018 at 7:46am -0500, Lars Ellenberg wrote: > As I understood it, > blkdev_issue_zeroout() was supposed to "always try to unmap", > deprovision, the relevant region, and zero-out any unaligned > head or tail, just like my work around above was doing. >

Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE

On Tue, Sep 19 2017 at 7:25pm -0400, Bart Van Assche wrote: > On Wed, 2017-09-20 at 06:44 +0800, Ming Lei wrote: > > For this issue, it isn't same between SCSI and dm-rq. > > > > We don't need to run queue in .end_io of dm, and the theory is > > simple, otherwise it

Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE

On Tue, Sep 19 2017 at 11:52am -0400, Bart Van Assche <bart.vanass...@wdc.com> wrote: > On Tue, 2017-09-19 at 11:48 -0400, Mike Snitzer wrote: > > This thread proves that it is definitely brittle to be relying on fixed > > delays like this: > > https://patchwo

Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE

On Tue, Sep 19 2017 at 11:36am -0400, Bart Van Assche wrote: > On Tue, 2017-09-19 at 13:43 +0800, Ming Lei wrote: > > On Mon, Sep 18, 2017 at 03:18:16PM +, Bart Van Assche wrote: > > > If you are still looking at removing the blk_mq_delay_run_hw_queue() calls > > >

Re: [PATCH 1/5] block: don't call blk_mq_delay_run_hw_queue() in case of BLK_STS_RESOURCE

On Tue, Sep 19 2017 at 1:43am -0400, Ming Lei wrote: > On Mon, Sep 18, 2017 at 03:18:16PM +, Bart Van Assche wrote: > > On Sun, 2017-09-17 at 20:40 +0800, Ming Lei wrote: > > > "if no request has completed before the delay has expired" can't be a > > > reason to rerun

Re: [v4.13-rc BUG] system lockup when running big buffered write(4M) to IB SRP via mpath

On Wed, Aug 23 2017 at 11:12am -0400, Bart Van Assche wrote: > On Wed, 2017-08-23 at 19:35 +0800, Ming Lei wrote: > > soft lockup still can be observed easily with patch d4acf3650c7c( > > block: Make blk_mq_delay_kick_requeue_list() rerun the queue at a quiet > > time),

Re: [for-4.14 RFC PATCH 1/2] dm rq: avoid deadlock if dm-mq is stacked on old .request_fn device(s)

On Fri, Jul 14 2017 at 1:17pm -0400, Ewan D. Milne <emi...@redhat.com> wrote: > On Fri, 2017-07-14 at 10:19 -0400, Mike Snitzer wrote: > > > > Do you see a benefit to extracting that portion of your WIP patch > > (removing the ->complete handler entirely)? >

Re: [for-4.14 RFC PATCH 1/2] dm rq: avoid deadlock if dm-mq is stacked on old .request_fn device(s)

On Fri, Jul 14 2017 at 3:22am -0400, Christoph Hellwig wrote: > The problem here is the following: > > blk_finish_request must always be called with the queue lock held, > it even has an assert. > > Without blk-mq used by dm-rq, dm uses the block softirq to execute the >

Re: [for-4.14 RFC PATCH 0/2] dm rq: eliminate historic blk-mq and .request_fn queue stacking restrictions

On Fri, Jul 14 2017 at 3:12am -0400, Christoph Hellwig wrote: > Btw, we might want to expedite this to 4.13, a 4.13 now defaults > to blk-mq for scsi, and this patch would make sure that dm keeps > on just working with that switch. Don't think we need to rush anything in response

[for-4.14 RFC PATCH 0/2] dm rq: eliminate historic blk-mq and .request_fn queue stacking restrictions

rameters/use_blk_mq echo Y > /sys/module/dm_mod/parameters/use_blk_mq echo Y > /sys/module/scsi_mod/parameters/use_blk_mq echo N > /sys/module/dm_mod/parameters/use_blk_mq echo N > /sys/module/scsi_mod/parameters/use_blk_mq echo Y > /sys/module/dm_mod/parameters/use_blk_mq Mike Sn

[for-4.14 RFC PATCH 2/2] dm rq: eliminate historic blk-mq and .request_fn queue stacking restrictions

quest it is possible to support all 4 permutations of stacking old .request_fn and blk-mq request_queues. Depends-on: eb8db831be ("dm: always defer request allocation to the owner of the request_queue") Reported-by: Ewan Milne <emi...@redhat.com> Signed-off-by: Mike Snitzer <snit

[for-4.14 RFC PATCH 1/2] dm rq: avoid deadlock if dm-mq is stacked on old .request_fn device(s)

-mq) ontop of old .request_fn devices is questionable. The above stack trace shows just how ugly it is to have old .request_fn SCSI code cascade into blk-mq code during DM multipath request completion. Signed-off-by: Mike Snitzer <snit...@redhat.com> --- drivers/md/dm-mpat

Re: [PATCH 25/27] block: remove the discard_zeroes_data flag

On Tue, May 02 2017 at 11:33pm -0400, Nicholas A. Bellinger wrote: > On Tue, 2017-05-02 at 09:23 +0200, h...@lst.de wrote: > > On Tue, May 02, 2017 at 12:16:13AM -0700, Nicholas A. Bellinger wrote: > > > Or, another options is use bdev_write_zeroes_sectors() to determine

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

On Tue, Apr 11 2017 at 1:51pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On Tue, 2017-04-11 at 13:47 -0400, Mike Snitzer wrote: > > Other drivers will very likely be caught about by > > this blk-mq quirk in the future. > > Hello Mike, > > A

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

On Tue, Apr 11 2017 at 12:26pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On Tue, 2017-04-11 at 12:09 -0400, Mike Snitzer wrote: > > This has no place in dm-mq (or any blk-mq > > driver). If it is needed it should be elevated to blk-m

Re: [PATCH v4 6/6] dm rq: Avoid that request processing stalls sporadically

-d -r 30 -t 02-mq; do :; done > > Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> > Cc: Mike Snitzer <snit...@redhat.com> > Cc: dm-de...@redhat.com > --- > drivers/md/dm-rq.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/md/dm

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 30 2017 at 11:20am -0400, Martin K. Petersen <martin.peter...@oracle.com> wrote: > Mike Snitzer <snit...@redhat.com> writes: > > > I can work on this now. Only question I have is: should DM thinp take > > care to zero any misaligned head and ta

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Thu, Mar 30 2017 at 11:22am -0400, Martin K. Petersen <martin.peter...@oracle.com> wrote: > Mike Snitzer <snit...@redhat.com> writes: > > > Would be very useful, particularly for testing, if > > drivers/scsi/scsi_debug.c were updated to support WRITE ZEROES.

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

Would be very useful, particularly for testing, if drivers/scsi/scsi_debug.c were updated to support WRITE ZEROES.

Re: [PATCH 22/23] drbd: implement REQ_OP_WRITE_ZEROES

On Thu, Mar 30 2017 at 7:44am -0400, Christoph Hellwig wrote: > On Thu, Mar 30, 2017 at 12:06:41PM +0200, Lars Ellenberg wrote: > > > Will it make an fstrim cause thinly provisioned > > devices to suddenly be fully allocated? > > Not for SCSI devices. Yes for dm-thinp until it

Re: [PATCH 03/23] sd: implement REQ_OP_WRITE_ZEROES

On Tue, Mar 28 2017 at 2:50pm -0400, Bart Van Assche wrote: > On Thu, 2017-03-23 at 10:33 -0400, Christoph Hellwig wrote: > > diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c > > index af632e350ab4..b6f70a09a301 100644 > > --- a/drivers/scsi/sd.c > > +++

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Mon, Mar 27 2017 at 5:10am -0400, Christoph Hellwig wrote: > It sounds like you don't want to support traditional discard at all, > but only WRITE ZEROES. So in many ways this series is the right way > forward. It would be nice if we could do a full blown >

Re: RFC: always use REQ_OP_WRITE_ZEROES for zeroing offload

On Thu, Mar 23 2017 at 11:54am -0400, Lars Ellenberg wrote: > On Thu, Mar 23, 2017 at 10:33:18AM -0400, Christoph Hellwig wrote: > > This series makes REQ_OP_WRITE_ZEROES the only zeroing offload > > supported by the block layer, and switches existing implementations >

Re: [PATCH 06/23] dm-kcopyd: switch to use REQ_OP_WRITE_ZEROES

On Thu, Mar 23 2017 at 10:56am -0400, Christoph Hellwig <h...@lst.de> wrote: > On Thu, Mar 23, 2017 at 10:55:22AM -0400, Mike Snitzer wrote: > > See commit 70d6c400a ("dm kcopyd: add WRITE SAME support to dm_kcopyd_zero") > > drivers/md/dm-io.c:do_region()

Re: [PATCH 06/23] dm-kcopyd: switch to use REQ_OP_WRITE_ZEROES

On Thu, Mar 23 2017 at 10:33am -0400, Christoph Hellwig wrote: > It seems like the code currently passes whatever it was using for writes > to WRITE SAME. Just switch it to WRITE ZEROES, although that doesn't > need any payload. > > Untested, and confused by the code, maybe

Re: [PATCHv3] scsi: use 'scsi_device_from_queue()' for scsi_dh

On Mon, Feb 20, 2017 at 10:22 PM, Martin K. Petersen wrote: >> "Hannes" == Hannes Reinecke writes: > > Hannes> The device handler needs to check if a given queue belongs to a > Hannes> scsi device; only then does it make sense to attach a device >

Re: [PATCHv2] scsi: use 'scsi_device_from_queue()' for scsi_dh

On Fri, Feb 17, 2017 at 3:27 AM, Christoph Hellwig wrote: > > On Fri, Feb 17, 2017 at 09:06:14AM +0100, Hannes Reinecke wrote: > > We could, but why? > > ATM we're only having SCSI devices able to use device handler; adding > > another layer of indirection doesn't solve anything

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Fri, Feb 17 2017 at 4:04am -0500, h...@infradead.org <h...@infradead.org> wrote: > On Thu, Feb 16, 2017 at 01:21:29PM -0500, Mike Snitzer wrote: > > multipath-tools has tables that specify all the defaults for a given > > target backend. NVMe will just be yet anothe

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Fri, Feb 17 2017 at 4:05am -0500, Christoph Hellwig wrote: > On Thu, Feb 16, 2017 at 08:05:36PM +0200, Sagi Grimberg wrote: > > I guess one config option that we'd need is multibus vs. failover > > which are used per use-case. > > Which fundamentally is a property of the

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Fri, Feb 17 2017 at 4:33am -0500, Christoph Hellwig <h...@infradead.org> wrote: > On Thu, Feb 16, 2017 at 10:13:37AM -0500, Mike Snitzer wrote: > > Not following what you're saying Keith did. Please feel free to > > clarify. > > Keith demonstrated what it takes t

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16 2017 at 1:07pm -0500, Keith Busch wrote: > On Thu, Feb 16, 2017 at 05:37:41PM +, Bart Van Assche wrote: > > On Thu, 2017-02-16 at 12:38 -0500, Keith Busch wrote: > > > Maybe I'm not seeing the bigger picture. Is there some part to multipath > > > that

Re: hch's native NVMe multipathing [was: Re: [PATCH 1/2] Don't blacklist nvme]

On Thu, Feb 16 2017 at 9:26am -0500, Christoph Hellwig <h...@infradead.org> wrote: > On Wed, Feb 15, 2017 at 09:53:57PM -0500, Mike Snitzer wrote: > > going to LSF/MM?). Yet you're expecting to just drop it into the tree > > without a care in the world about the implication

Re: [PATCH 1/2] Don't blacklist nvme

On Wed, Feb 15 2017 at 9:01pm -0500, Mike Snitzer <snit...@redhat.com> wrote: > On Tue, Feb 14 2017 at 6:00pm -0500, > Keith Busch <keith.bu...@intel.com> wrote: > > > On Tue, Feb 14, 2017 at 01:35:45PM -0800, Bart Van Assche wrote: > > > On 02

Re: [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

On Fri, Jan 27 2017 at 11:36am -0500, Christoph Hellwig <h...@lst.de> wrote: > On Fri, Jan 27, 2017 at 11:34:34AM -0500, Mike Snitzer wrote: > > Noticed after further review that it seems a bit weird to have the non > > blk-mq support in drivers calling blk_mq_rq_to_pdu

Re: [PATCH 07/18] dm: always defer request allocation to the owner of the request_queue

a further step. > > Signed-off-by: Christoph Hellwig <h...@lst.de> > Reviewed-by: Hannes Reinecke <h...@suse.com> > Reviewed-by: Mike Snitzer <snit...@redhat.com> ... > diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c > index 3f12916..8d06834 100644 > ---

Re: [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Tue, Jan 24 2017 at 9:20am -0500, Christoph Hellwig <h...@lst.de> wrote: > On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote: > > possible and is welcomed cleanup. The only concern I have is that using > > get_request() for the old request_fn req

Re: [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On Mon, Jan 23 2017 at 10:29am -0500, Christoph Hellwig wrote: > DM already calls blk_mq_alloc_request on the request_queue of the > underlying device if it is a blk-mq device. But now that we allow drivers > to allocate additional data and initialize it ahead of time we need to do

Re: [LSF/MM TOPIC][LSF/MM ATTEND] multipath redesign

On Fri, Jan 13 2017 at 10:56am -0500, Hannes Reinecke <h...@suse.de> wrote: > On 01/12/2017 06:29 PM, Benjamin Marzinski wrote: > > On Thu, Jan 12, 2017 at 09:27:40AM +0100, Hannes Reinecke wrote: > >> On 01/11/2017 11:23 PM, Mike Snitzer wrote: > >>>

Re: [PATCH 05/15] dm: remove incomple BLOCK_PC support

On Thu, Jan 12 2017 at 3:00am -0500, Christoph Hellwig <h...@lst.de> wrote: > On Wed, Jan 11, 2017 at 08:09:37PM -0500, Mike Snitzer wrote: > > I'm not following your reasoning. > > > > dm_blk_ioctl calls __blkdev_driver_ioctl and will call scsi_cmd_ioctl > >

Re: [PATCH 05/15] dm: remove incomple BLOCK_PC support

On Tue, Jan 10 2017 at 10:06am -0500, Christoph Hellwig wrote: > DM tries to copy a few fields around for BLOCK_PC requests, but given > that no dm-target ever wires up scsi_cmd_ioctl BLOCK_PC can't actually > be sent to dm. > > Signed-off-by: Christoph Hellwig > ---

Re: RFC: split scsi passthrough fields out of struct request

On Tue, Jan 10 2017 at 10:06am -0500, Christoph Hellwig wrote: > Hi all, > > this series splits the support for SCSI passthrough commands from the > main struct request used all over the block layer into a separate > scsi_request structure that drivers that want to support SCSI

Re: [LSF/MM TOPIC][LSF/MM ATTEND] multipath redesign

On Wed, Jan 11 2017 at 4:44am -0500, Hannes Reinecke wrote: > Hi all, > > I'd like to attend LSF/MM this year, and would like to discuss a > redesign of the multipath handling. > > With recent kernels we've got quite some functionality required for > multipathing already

Re: [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue

On Wed, Jan 11 2017 at 4:37am -0500, Hannes Reinecke wrote: > On 01/11/2017 10:01 AM, Christoph Hellwig wrote: > > On Wed, Jan 11, 2017 at 09:59:17AM +0100, Hannes Reinecke wrote: > >> I'd advocate to discuss this at LSF. > >> Now that Mike moved the bio-based mpath stuff back in

Re: [PATCH 14/15] block/bsg: move queue creation into bsg_setup_queue

On Wed, Jan 11 2017 at 3:45am -0500, Christoph Hellwig wrote: > On Wed, Jan 11, 2017 at 09:42:44AM +0100, Johannes Thumshirn wrote: > > On Tue, Jan 10, 2017 at 04:06:19PM +0100, Christoph Hellwig wrote: > > > Simply the boilerplate code needed for bsg nodes a bit. > > > > > >

[LSF/MM TOPIC ATTEND] multipath for NVMe over Fabrics

I'd like to discuss $subject. I haven't heard of much progress on this (but I'm also not tracking NVMe development at the moment). Last I heard about getting DM multipath to work with NVMe over Fabrics was this: https://patchwork.kernel.org/patch/9208997/ I've reintroduced bio-based support for

Re: [PATCH 08/12] dm: Fix a race condition related to stopping and starting queues

path+0xa6/0xa8 > > Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> > Reviewed-by: Hannes Reinecke <h...@suse.com> > Reviewed-by: Johannes Thumshirn <jthumsh...@suse.de> > Reviewed-by: Christoph Hellwig <h...@lst.de> > Cc: Mike Snitzer <sn

Re: [PATCH 07/12] dm: Use BLK_MQ_S_STOPPED instead of QUEUE_FLAG_STOPPED in blk-mq code

stopped() tests into blk_mq_queue_stopped(). > > Signed-off-by: Bart Van Assche <bart.vanass...@sandisk.com> > Reviewed-by: Christoph Hellwig <h...@lst.de> > Cc: Mike Snitzer <snit...@redhat.com> Acked-by: Mike Snitzer <snit...@redhat.com> -- To unsubscribe from this list: send the lin

Re: dm-mpath: always return reservation conflict

g wrote: > > > > Getting back to this after Hannes recovered from his vacation > > > > and I had a chat with him.. > > > > > > > > On Mon, Aug 15, 2016 at 09:40:39AM -0400, Mike Snitzer wrote: > > > > > Seems we still need a more sophis

Re: [PATCH 0/9] Introduce blk_quiesce_queue() and blk_resume_queue()

On Mon, Sep 26 2016 at 2:25pm -0400, Bart Van Assche wrote: > Hello Jens, > > Multiple block drivers need the functionality to stop a request > queue and to wait until all ongoing request_fn() / queue_rq() calls > have finished without waiting until all outstanding

Re: dm-mpath: always return reservation conflict

On Mon, Aug 15 2016 at 9:08P -0400, Mike Snitzer <snit...@redhat.com> wrote: > Not sure how Hannes' original patch was overlooked but... It wasn't overlooked. It was very much unresolved. The original thread unraveled to all sorts of PR edge case concerns (and doubt about whether

Re: dm-mpath: always return reservation conflict

Not sure how Hannes' original patch was overlooked but... One issue I see with the patch is it will return -EBADE regardless of whether 'queue_if_no_path' is set. That's fine (since path isn't being failed for this case any more). But why not just return error immediately? But taking a step

Re: dm-mq and end_clone_request()

I've staged another fix, Laurence is seeing success with this added: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.8=d50a6450104c237db1dc75314d17b78c990a8c05 I'll be sending all the fixes I've queued to Linus tonight or early tomorrow (since I'll then be

Re: dm-mq and end_clone_request()

On Tue, Aug 02 2016 at 9:33pm -0400, Laurence Oberman wrote: > Hi Bart > > I simplified the test to 2 simple scripts and only running against one XFS > file system. > Can you validate these and tell me if its enough to emulate what you are > doing. > Perhaps our

Re: dm-mq and end_clone_request()

On Tue, Aug 02 2016 at 8:19pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 08/02/2016 10:45 AM, Mike Snitzer wrote: > > Please do these same tests against a v4.7 kernel with the 4 patches from > > this branch applied (no need for your other debu

Re: dm-mq and end_clone_request()

On Mon, Aug 01 2016 at 6:41pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 08/01/2016 01:46 PM, Mike Snitzer wrote: > > Please retry both variant (CONFIG_DM_MQ_DEFAULT=y first) with this patch > > applied. Interested to see if things look better f

Re: dm-mq and end_clone_request()

On Mon, Aug 01 2016 at 2:55P -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 08/01/2016 10:59 AM, Mike Snitzer wrote: > >This says to me that must_push_back is returning false because > >dm_noflush_suspending() is false. When this happens -EIO will esca

Re: dm-mq and end_clone_request()

On Mon, Aug 01 2016 at 2:55pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 08/01/2016 10:59 AM, Mike Snitzer wrote: > >This says to me that must_push_back is returning false because > >dm_noflush_suspending() is false. When this happens -EIO will esca

Re: dm-mq and end_clone_request()

With this debug patch ontop of v4.7: diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c index 52baf8a..22baf29 100644 --- a/drivers/md/dm-mpath.c +++ b/drivers/md/dm-mpath.c @@ -433,10 +433,22 @@ failed: */ static int must_push_back(struct multipath *m) { + bool queue_if_no_path

Re: dm-mq and end_clone_request()

On Thu, Jul 28 2016 at 11:23am -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/28/2016 06:33 AM, Mike Snitzer wrote: > >On Wed, Jul 27 2016 at 7:05pm -0400, > >Bart Van Assche <bart.vanass...@sandisk.com> wrote: > >>Thanks again for

Re: dm-mq and end_clone_request()

On Wed, Jul 27 2016 at 7:05pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/27/2016 01:09 PM, Mike Snitzer wrote: > > In addition to the above patch, please apply this patch and retest your > >4.7 kernel: > > > >diff --git a/drivers/md/d

Re: dm-mq and end_clone_request()

On Mon, Jul 25 2016 at 9:16pm -0400, Mike Snitzer <snit...@redhat.com> wrote: > Hi Bart, > > Please try this patch to see if it fixes your issue, thanks. > > diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c > index 52baf8a..287caa7 100644 > --- a/dr

Re: dm-mq and end_clone_request()

On Wed, Jul 27 2016 at 3:06pm -0400, Bart Van Assche wrote: > On 07/27/2016 08:52 AM, Benjamin Marzinski wrote: > >if you look in drivers/md/dm-ioctl.c at do_resume(), device mapper > >internally does a suspend when you call resume with a new table loaded. > >That's

Re: dm-mq and end_clone_request()

On Tue, Jul 26 2016 at 6:51pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/25/2016 06:15 PM, Mike Snitzer wrote: > > Please try this patch to see if it fixes your issue, thanks. > > > > diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c

Re: dm-mq and end_clone_request()

On Mon, Jul 25 2016 at 6:00P -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/25/2016 02:23 PM, Mike Snitzer wrote: > >So I'd be curious to know if your debugging has enabled you to identify > >exactly where in the dm-mapth.c code the -EIO return is

Re: dm-mq and end_clone_request()

On Mon, Jul 25 2016 at 1:53pm -0400, Mike Snitzer <snit...@redhat.com> wrote: > On Thu, Jul 21 2016 at 4:58pm -0400, > Bart Van Assche <bart.vanass...@sandisk.com> wrote: > > > On 07/20/2016 11:33 AM, Mike Snitzer wrote: > > >Would be interesting to know the

Re: dm-mq and end_clone_request()

On Thu, Jul 21 2016 at 4:58pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/20/2016 11:33 AM, Mike Snitzer wrote: > >Would be interesting to know the error returned from map_request()'s > >ti->type->clone_and_map_rq(). Really shou

Re: dm-mq and end_clone_request()

On Wed, Jul 20 2016 at 1:37pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/20/2016 07:27 AM, Mike Snitzer wrote: > >On Wed, Jul 20 2016 at 10:08am -0400, > >Mike Snitzer <snit...@redhat.com> wrote: > >[ ... ] > >diff --git a/drivers/m

Re: dm-mq and end_clone_request()

On Wed, Jul 20 2016 at 1:37pm -0400, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 07/20/2016 07:27 AM, Mike Snitzer wrote: > >On Wed, Jul 20 2016 at 10:08am -0400, > >Mike Snitzer <snit...@redhat.com> wrote: > >[ ... ] > >diff --git a/drivers/m

Re: dm-mq and end_clone_request()

On Wed, Jul 20 2016 at 10:08am -0400, Mike Snitzer <snit...@redhat.com> wrote: > On Tue, Jul 19 2016 at 6:57pm -0400, > Bart Van Assche <bart.vanass...@sandisk.com> wrote: > > > Hello Mike, > > > > If I run a fio data integrity test against kernel v4.7-rc

Re: dm-mq and end_clone_request()

On Tue, Jul 19 2016 at 6:57pm -0400, Bart Van Assche wrote: > Hello Mike, > > If I run a fio data integrity test against kernel v4.7-rc7 then I > see often that fio reports I/O errors if a path is removed despite > queue_if_no_path having been set in

Re: PR API fixes for multipathing

On Sat, Jul 16 2016 at 2:14pm -0400, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Sat, 2016-07-16 at 14:10 -0400, Mike Snitzer wrote: > > On Fri, Jul 15 2016 at 9:08pm -0400, > > Christoph Hellwig <h...@lst.de> wrote: > > > > >

Re: PR API fixes for multipathing

On Fri, Jul 15 2016 at 9:08pm -0400, Christoph Hellwig wrote: > On Fri, Jul 15, 2016 at 03:03:54PM -0400, Martin K. Petersen wrote: > > > "Christoph" == Christoph Hellwig writes: > > > > Christoph> I was a bit overeager to thing ALL_TG_PT would solve all our > >

Re: block: don't check request size in blk_cloned_rq_check_limits()

On Tue, Jun 14 2016 at 9:39pm -0400, Martin K. Petersen wrote: > > "Hannes" == Hannes Reinecke writes: > > Hannes> Well, the primary issue is that 'blk_cloned_rq_check_limits()' > Hannes> doesn't check for BLOCK_PC, > > Yes it does. It calls

Re: block: don't check request size in blk_cloned_rq_check_limits()

On Fri, Jun 10 2016 at 9:30am -0400, Hannes Reinecke <h...@suse.de> wrote: > On 06/10/2016 03:19 PM, Mike Snitzer wrote: > > On Mon, May 30 2016 at 3:24am -0400, > > Hannes Reinecke <h...@suse.de> wrote: > > > >> When checking a cloned request there is

Re: block: don't check request size in blk_cloned_rq_check_limits()

On Mon, May 30 2016 at 3:24am -0400, Hannes Reinecke wrote: > When checking a cloned request there is no need to check > the overall request size; this won't have changed even > when resubmitting to another queue. > Without this patch ppc64le on ibmvfc fails to boot. By simply

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 <h...@suse.de> wrote: > On 05/27/2016 04:44 PM, Mike Snitzer wrote: > >On Fri, May 27 2016 at 4:39am -0400, > >Hannes Reinecke <h...@suse.de> wrote: > > > [ .. ] > >>No, the real issue is load-bala

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 <h...@suse.de> wrote: > On 05/26/2016 04:38 AM, Mike Snitzer wrote: > >On Thu, Apr 28 2016 at 11:40am -0400, > >James Bottomley <james.bottom...@hansenpartnership.com> wrote: > > > >>On Thu, 201

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 <james.bottom...@hansenpartnership.com> 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 reall

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

On Wed, Apr 27 2016 at 7:39pm -0400, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > Multipath - Mike Snitzer > > > Mike began with a request for feedback, which quickly lead to the > complaint that recovery time (and how

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

On Fri, Apr 15 2016 at 3:15pm -0400, mchri...@redhat.com wrote: > The following patches begin to cleanup the request->cmd_flags and > bio->bi_rw mess. We currently use cmd_flags to specify the operation, > attributes and state of the request. For bi_rw we use it for similar

  1   2   >