On Thu, Jul 18 2019 at 9:35pm -0400,
Ming Lei wrote:
> On Thu, Jul 18, 2019 at 10:52:01AM -0400, Mike Snitzer wrote:
> > On Wed, Jul 17 2019 at 11:25pm -0400,
> > Ming Lei wrote:
> >
> > > dm-rq needs to free request which has been dispatched and not compl
issue.
>
> Another use case is to free request when the hctx is dead during
> cpu hotplug context.
>
> Cc: Ewan D. Milne
> Cc: Bart Van Assche
> Cc: Hannes Reinecke
> Cc: Christoph Hellwig
> Cc: Mike Snitzer
> Cc: dm-de...@redhat.com
> Cc:
> Fixes: 3
On Mon, Oct 29 2018 at 10:25am -0400,
Jens Axboe wrote:
> On 10/29/18 1:10 AM, Hannes Reinecke wrote:
> > On 10/25/18 11:10 PM, Jens Axboe wrote:
> >> Nobody sets the helper, so we always return 0. Kill it.
> >>
> >> Signed-off-by: Jens Axboe
> >> ---
> >> block/blk-core.c | 28 -
On Tue, Oct 23 2018 at 10:26pm -0400,
Martin K. Petersen wrote:
>
> Jens,
>
> > 2) The ordering of the signed-off-by. Someone told me that this is
> >patchwork, but I absolutely hate it. SOB should go last, not before
> >the reviewed-by. I fixed that up too.
>
> You keep mentioning thi
elease_queue() using the block internal function
> blk_queue_free_zone_bitmaps().
>
> Signed-off-by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
> Reviewed-by: Christoph Hellwig
Reviewed-by: Mike Snitzer
upport for null_blk, dm-linear and dm-flakey.
> Signed-off-by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
Reviewed-by: Mike Snitzer
On Wed, Oct 10 2018 at 10:15am -0400,
Mike Snitzer wrote:
> On Tue, Oct 09 2018 at 9:52pm -0400,
> Damien Le Moal wrote:
>
> > From: Christoph Hellwig
> >
> > Dispatching a report zones command through the request queue is a major
> > pain due to th
On Tue, Oct 09 2018 at 9:52pm -0400,
Damien Le Moal wrote:
> From: Christoph Hellwig
>
> Dispatching a report zones command through the request queue is a major
> pain due to the command reply payload rewriting necessary. Given that
> blkdev_report_zones() is executing everything synchronously
On Tue, Oct 09 2018 at 9:52pm -0400,
Damien Le Moal wrote:
> From: Christoph Hellwig
>
> Dispatching a report zones command through the request queue is a major
> pain due to the command reply payload rewriting necessary. Given that
> blkdev_report_zones() is executing everything synchronously
On Mon, Sep 17 2018 at 10:51am -0400,
Bart Van Assche wrote:
> On 9/17/18 7:20 AM, Mike Snitzer wrote:
> >>- Avoid that m->hw_handler_name becomes a dangling pointer if the
> >> RETAIN_ATTACHED_HW_HANDLER flag is set and scsi_dh_attach() returns
> >> -EBUSY.
[dropping stable@ cc and cc'ing linux-scsi instead]
On Sun, Sep 16 2018 at 11:33pm -0400,
Bart Van Assche wrote:
> This patch fixes two bugs that got introduced recently in setup_scsi_dh():
> - Avoid that a memory leak occurs if attached_handler_name is not assigned
> to m->hw_handler_name.
I
On Fri, Mar 30 2018 at 5:04P -0400,
Michael Ellerman wrote:
> Hi Mike,
>
> Paul's AFK so I tried the patch you sent.
>
> Mike Snitzer writes:
> > On Thu, Mar 29 2018 at 4:39am -0400,
> > Paul Mackerras wrote:
> >> Since commit 8d47e65948dd ("dm
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 adapters are IPR and the u
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 unnecessary
> NVMe branchin
On Mon, Mar 05 2018 at 2:23am -0500,
Kashyap Desai wrote:
> > -Original Message-
> > From: Laurence Oberman [mailto:lober...@redhat.com]
> > Sent: Saturday, March 3, 2018 3:23 AM
> > To: Don Brace; Ming Lei
> > Cc: Jens Axboe; linux-bl...@vger.kerne
On Tue, Jan 30 2018 at 9:44P -0500,
Jens Axboe wrote:
> On 1/30/18 7:24 AM, Mike Snitzer wrote:
> > From: Ming Lei
> >
> > This status is returned from driver to block layer if device related
> > resource is unavailable, but driver can guarantee that IO dispat
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
Tested-by: Laurence Oberman
Signed-off-by: Ming Lei
Signed-off-by: Mike Snitzer
---
V6:
- use -EBUSY, instead of -ENOMEM, for BLK_STS_DEV_RES
On Tue, Jan 30 2018 at 2:42pm -0500,
Bart Van Assche 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 wrote:
> >
> > > - This patch does not fix any bugs nor makes block drivers easier t
On Tue, Jan 30 2018 at 12:52pm -0500,
Bart Van Assche 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 a delay to avoid IO stalls
> >
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
Tested-by: Laurence Oberman
Signed-off-by: Ming Lei
Signed-off-by: Mike Snitzer
---
V5:
- fixed stale reference to 10ms delay in blk-mq.c co
On Mon, Jan 29 2018 at 4:51pm -0500,
Bart Van Assche 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 the queue is not sufficient. Wi
On Mon, Jan 29 2018 at 4:22pm -0500,
Bart Van Assche 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 10ms to avoid IO stalls
> > +
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 disabled at default too.
>
BLK_STS_RESOURCE and SCHED_RESTART is set, rerun queue after
a delay (BLK_MQ_DELAY_QUEUE) to avoid IO stalls. BLK_MQ_DELAY_QUEUE is
3 ms because both scsi-mq and nvmefc are using that magic value.
Suggested-by: Jens Axboe
Tested-by: Laurence Oberman
Signed-off-by: Ming Lei
Signed-off-by: Mike Snitzer
On Sat, Jan 27 2018 at 10:00pm -0500,
Bart Van Assche 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 clean up in the face of
> &g
On Sat, Jan 27 2018 at 7:54pm -0500,
Bart Van Assche 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 describe these interactions.
> >
On Sat, Jan 27 2018 at 5:12pm -0500,
Bart Van Assche 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 path) and Bart's (02-mq with
&g
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 this patch is as follows:
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
> Tested-by: Laurence Oberman
> Cc: Christoph Hellwig
> Cc: Mike Snitzer
> Cc:
On Sat, Jan 20 2018 at 7:57pm -0500,
Ming Lei 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 wrote:
> >
> > > This status is returned from driver to block layer if device related
>
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
> Cc: Mike Snitzer
> Cc: Laurence Oberman
> Cc: Bart Van Assche
> Signed-off-
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.
>
> And that device mapper t
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 isn't performance issue, and
On Tue, Sep 19 2017 at 11:52am -0400,
Bart Van Assche 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://patchwork.kernel.org/patch/9703249/
>
>
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
> > > then I think you are lookin
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 the queue, because the
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),
> > but no hard lockup.
>
On Fri, Jul 14 2017 at 1:17pm -0400,
Ewan D. Milne 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)?
> >
> > Or leave we
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
> completion, which mean
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 to that change
ule/scsi_mod/parameters/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_
request 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
Signed-off-by: Mike Snitzer
---
drivers/md/dm-rq.c
dm-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
---
drivers/md/dm-mpath.c | 16 ++--
dri
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 when
> > > dev_attrib->un
On Tue, Apr 11 2017 at 1:51pm -0400,
Bart Van Assche 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,
>
> Are you aware that the requirement th
On Tue, Apr 11 2017 at 12:26pm -0400,
Bart Van Assche 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-mq core to
> > trigger blk_mq_dela
t;
> Signed-off-by: Bart Van Assche
> Cc: Mike Snitzer
> Cc: dm-de...@redhat.com
> ---
> drivers/md/dm-rq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index 6886bf160fb2..d19af1d21f4c 100644
> --- a/driver
On Thu, Mar 30 2017 at 11:20am -0400,
Martin K. Petersen wrote:
> Mike Snitzer writes:
>
> > I can work on this now. Only question I have is: should DM thinp take
> > care to zero any misaligned head and tail? (I assume so but with all
> > the back and forth between
On Thu, Mar 30 2017 at 11:22am -0400,
Martin K. Petersen wrote:
> Mike Snitzer writes:
>
> > Would be very useful, particularly for testing, if
> > drivers/scsi/scsi_debug.c were updated to support WRITE ZEROES.
>
> There is no WRITE ZEROES in SCSI. You should
Would be very useful, particularly for testing, if
drivers/scsi/scsi_debug.c were updated to support 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 implements
> RE
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
> > +++ b/drivers/scsi/sd.c
> > @@ -748,7 +748,
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
> REQ_OP_WRITE_ZEROES for dm_think
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
> > of REQ_OP_DISCARD that co
On Thu, Mar 23 2017 at 10:56am -0400,
Christoph Hellwig 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() adjusts the WRITE SAME p
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 someone who understa
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
> Hannes> handler.
>
> Fixed kbuild warning and
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 here.
> > Moving t
On Fri, Feb 17 2017 at 4:04am -0500,
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 another.
>
> No, if we get
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 target first, and it
On Fri, Feb 17 2017 at 4:33am -0500,
Christoph Hellwig 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 to support NVMe with dm
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 the kernel is not in a be
On Thu, Feb 16 2017 at 9:26am -0500,
Christoph Hellwig 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 implications.
>
> I
On Wed, Feb 15 2017 at 9:01pm -0500,
Mike Snitzer wrote:
> On Tue, Feb 14 2017 at 6:00pm -0500,
> Keith Busch wrote:
>
> > On Tue, Feb 14, 2017 at 01:35:45PM -0800, Bart Van Assche wrote:
> > > On 02/14/2017 01:19 PM, Keith Busch wrote:
> > > > These dev
On Fri, Jan 27 2017 at 11:36am -0500,
Christoph Hellwig 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(). But I&#
p.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Hannes Reinecke
> Reviewed-by: Mike Snitzer
...
> diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> index 3f12916..8d06834 100644
> --- a/drivers/md/dm-rq.c
> +++ b/drivers/md/dm-rq.c
> @@ -185,7 +163,7 @@ static voi
On Tue, Jan 24 2017 at 9:20am -0500,
Christoph Hellwig 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 request_queue eliminates the
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
> the same fo
On Fri, Jan 13 2017 at 10:56am -0500,
Hannes Reinecke 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:
> >>> On Wed, Jan 11 2017 at 4:44a
On Thu, Jan 12 2017 at 3:00am -0500,
Christoph Hellwig 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
> >
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
> ---
> drivers/md/dm-rq.c | 16
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 passthough
> need
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 implemented, making so
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 things got even
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.
> > >
> > > Signed-off-by: Chr
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
y: Bart Van Assche
> Reviewed-by: Hannes Reinecke
> Reviewed-by: Johannes Thumshirn
> Reviewed-by: Christoph Hellwig
> Cc: Mike Snitzer
Acked-by: Mike Snitzer
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; Signed-off-by: Bart Van Assche
> Reviewed-by: Christoph Hellwig
> Cc: Mike Snitzer
Acked-by: Mike Snitzer
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
is 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 sophisticated approach. But I'm
> > >
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 requests have
> finished. Hen
On Mon, Aug 15 2016 at 9:08P -0400,
Mike Snitzer 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
anything relies o
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 bac
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&id=d50a6450104c237db1dc75314d17b78c990a8c05
I'll be sending all the fixes I've queued to Linus tonight or early
tomorrow (since I'll then be
On Wed, Aug 03 2016 at 12:55pm -0400,
Bart Van Assche wrote:
> On 08/02/2016 05:40 PM, Mike Snitzer wrote:
> >But I asked you to run the v4.7 kernel patches I
> >pointed to _without_ any of your debug patches.
>
> I need several patches to fix bugs that are not related t
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 test-suite is too simple.
>
>
On Tue, Aug 02 2016 at 8:19pm -0400,
Bart Van Assche 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 debug patches):
> > https://git.kernel.org/
On Mon, Aug 01 2016 at 6:41pm -0400,
Bart Van Assche 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 for you (WARN_ON_ONCEs
> > added just
On Mon, Aug 01 2016 at 2:55P -0400,
Bart Van Assche 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 escape up
> >the IO stack.
> >
On Mon, Aug 01 2016 at 2:55pm -0400,
Bart Van Assche 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 escape up
> >the IO stack.
> >
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
On Thu, Jul 28 2016 at 11:23am -0400,
Bart Van Assche wrote:
> On 07/28/2016 06:33 AM, Mike Snitzer wrote:
> >On Wed, Jul 27 2016 at 7:05pm -0400,
> >Bart Van Assche wrote:
> >>Thanks again for having made this patch available. I will test it as
> >>soo
On Wed, Jul 27 2016 at 7:05pm -0400,
Bart Van Assche 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/dm-mpath.c b/drivers/md/dm-mpath.c
>
On Mon, Jul 25 2016 at 9:16pm -0400,
Mike Snitzer 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/drivers/md/dm-mpath.c
> +++
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 when these suspends are happe
On Tue, Jul 26 2016 at 6:51pm -0400,
Bart Van Assche 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
> > index 52baf8a..287caa7
On Mon, Jul 25 2016 at 6:00P -0400,
Bart Van Assche 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 being
> >established.
On Mon, Jul 25 2016 at 1:53pm -0400,
Mike Snitzer wrote:
> On Thu, Jul 21 2016 at 4:58pm -0400,
> Bart Van Assche wrote:
>
> > On 07/20/2016 11:33 AM, Mike Snitzer wrote:
> > >Would be interesting to know the error returned from map_request()'s
> > >
On Thu, Jul 21 2016 at 4:58pm -0400,
Bart Van Assche 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 should just be DM_MAPIO_REQUEUE.
> >But
On Wed, Jul 20 2016 at 1:37pm -0400,
Bart Van Assche wrote:
> On 07/20/2016 07:27 AM, Mike Snitzer wrote:
> >On Wed, Jul 20 2016 at 10:08am -0400,
> >Mike Snitzer wrote:
> >[ ... ]
> >diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> >index 7a96618..347f
On Wed, Jul 20 2016 at 1:37pm -0400,
Bart Van Assche wrote:
> On 07/20/2016 07:27 AM, Mike Snitzer wrote:
> >On Wed, Jul 20 2016 at 10:08am -0400,
> >Mike Snitzer wrote:
> >[ ... ]
> >diff --git a/drivers/md/dm-rq.c b/drivers/md/dm-rq.c
> >index 7a96618..347f
1 - 100 of 214 matches
Mail list logo
