Re: [dm-devel] [PATCH 0/5] Failover criteria unification

On Thu, Jan 04 2018 at 6:47pm -0500, Keith Busch wrote: > On Thu, Jan 04, 2018 at 06:36:27PM -0500, Mike Snitzer wrote: > > Right, I dropped that patch since it'd have only resulted in conflicts > > come merge time. As such, this series can easily go through the nvme > >

Re: [dm-devel] [PATCH 0/5] Failover criteria unification

On Thu, Jan 04, 2018 at 06:36:27PM -0500, Mike Snitzer wrote: > Right, I dropped that patch since it'd have only resulted in conflicts > come merge time. As such, this series can easily go through the nvme > tree to Jens. It looks like you can also touch up dm to allow it to multipath nvme even

Re: [dm-devel] [PATCH 5/5] dm mpath: Use blk_retryable

On Thu, Jan 04 2018 at 5:46pm -0500, Keith Busch wrote: > Uses common code for determining if an error should be retried on > alternate path. > > Signed-off-by: Keith Busch Acked-by: Mike Snitzer -- dm-devel mailing list

Re: [dm-devel] [PATCH 2/5] nvme/multipath: Consult blk_status_t for failover

On Thu, Jan 04 2018 at 5:46pm -0500, Keith Busch wrote: > This removes nvme multipath's specific status decoding to see if failover > is needed, using the generic blk_status_t that was translated earlier. This > abstraction from the raw NVMe status means nvme status

Re: [dm-devel] [PATCH 3/5] block: Provide blk_status_t decoding for retryable errors

On Thu, Jan 04 2018 at 5:46pm -0500, Keith Busch wrote: > This patch provides a common decoder for block status that may be retried > so various entities wishing to consult this do not have to duplicate > this decision. > > Signed-off-by: Keith Busch

Re: [dm-devel] [PATCH 0/5] Failover criteria unification

On Thu, Jan 04 2018 at 5:46pm -0500, Keith Busch wrote: > The nvme native multipath provided a separate NVMe status decoder, > complicating maintenance as new statuses need to be accounted for. This > was already diverging from the generic nvme status decoder, which has >

Re: [dm-devel] [PATCH 4/5] nvme/multipath: Use blk_retryable

On Thu, Jan 04 2018 at 5:46pm -0500, Keith Busch wrote: > Uses common code for determining if an error should be retried on > alternate path. > > Signed-off-by: Keith Busch Acked-by: Mike Snitzer -- dm-devel mailing list

Re: [dm-devel] [PATCH 1/5] nvme: Add more command status translation

On Thu, Jan 04 2018 at 5:46pm -0500, Keith Busch wrote: > This adds more NVMe status code translations to blk_status_t values, > and captures all the current status codes NVMe multipath uses. > > Signed-off-by: Keith Busch Acked-by: Mike Snitzer

[dm-devel] [PATCH 5/5] dm mpath: Use blk_retryable

Uses common code for determining if an error should be retried on alternate path. Signed-off-by: Keith Busch --- drivers/md/dm-mpath.c | 19 ++- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c

[dm-devel] [PATCH 4/5] nvme/multipath: Use blk_retryable

Uses common code for determining if an error should be retried on alternate path. Signed-off-by: Keith Busch --- drivers/nvme/host/multipath.c | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/drivers/nvme/host/multipath.c

[dm-devel] [PATCH 1/5] nvme: Add more command status translation

This adds more NVMe status code translations to blk_status_t values, and captures all the current status codes NVMe multipath uses. Signed-off-by: Keith Busch --- drivers/nvme/host/core.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/nvme/host/core.c

[dm-devel] [PATCH 3/5] block: Provide blk_status_t decoding for retryable errors

This patch provides a common decoder for block status that may be retried so various entities wishing to consult this do not have to duplicate this decision. Signed-off-by: Keith Busch --- include/linux/blk_types.h | 16 1 file changed, 16 insertions(+)

[dm-devel] [PATCH 2/5] nvme/multipath: Consult blk_status_t for failover

This removes nvme multipath's specific status decoding to see if failover is needed, using the generic blk_status_t that was translated earlier. This abstraction from the raw NVMe status means nvme status decoding exists in just one place. Signed-off-by: Keith Busch ---

[dm-devel] [PATCH 0/5] Failover criteria unification

The nvme native multipath provided a separate NVMe status decoder, complicating maintenance as new statuses need to be accounted for. This was already diverging from the generic nvme status decoder, which has implications for other components that rely on accurate generic block errors. This

Re: [dm-devel] dm bufio: fix shrinker scans when (nr_to_scan < retain_target)

This was already included as of v4.15-rc4 via commit fbc7c07ec2 ("dm bufio: fix shrinker scans when (nr_to_scan < retain_target)") I even cc'd you on the relevant pull request that I sent to Linus, see: https://www.redhat.com/archives/dm-devel/2017-December/msg00119.html Mike On Thu, Jan 04

Re: [dm-devel] [PATCH v6 0/2] dax, dm: stop requiring dax for device-mapper

On Wed, Nov 29 2017 at 1:59pm -0500, Dan Williams wrote: > Changes since v5 [1]: > * Make DAX_DRIVER select DAX to simplify the Kconfig dependencies > (Michael) > * Rebase on 4.15-rc1 and add new IS_ENABLED(CONFIG_DAX_DRIVER) checks in > drivers/md/dm-log-writes.c.

Re: [dm-devel] dm bufio: fix missed destroy of mutex c->lock

I already staged a similar fix, see: https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.16=cfb0bd8b25eb90faa7cbbad9a52ad2c33102123e On Thu, Jan 04 2018 at 9:08am -0500, Xiongwei Song wrote: > The mutex c->lock is initialized in

Re: [dm-devel] [for-4.16 PATCH v2 0/5] block, nvme, dm: allow DM multipath to use NVMe's error handler

On Thu, Jan 04 2018 at 5:26am -0500, Christoph Hellwig wrote: > On Tue, Jan 02, 2018 at 04:29:43PM -0700, Keith Busch wrote: > > Instead of hiding NVMe path related errors, the NVMe driver needs to > > code an appropriate generic block status from an NVMe status. > > > > We

Re: [dm-devel] [PATCH] dm bufio: fix missed destroy of mutex c->lock

2018-01-04 22:08 GMT+08:00 Xiongwei Song : > The mutex c->lock is initialized in dm_bufio_client_create, however, > it is not destroyed before free the structure of dm_bufio_client in > dm_bufio_client_destroy. > > Signed-off-by: Xiongwei Song > --- >

[dm-devel] [PATCH] dm bufio: fix missed destroy of mutex c->lock

The mutex c->lock is initialized in dm_bufio_client_create, however, it is not destroyed before free the structure of dm_bufio_client in dm_bufio_client_destroy. Signed-off-by: Xiongwei Song --- drivers/md/dm-bufio.c | 1 + 1 file changed, 1 insertion(+) diff --git

[dm-devel] [PATCH] dm bufio: fix missed destroy of mutex c->lock

The mutex c->lock is initialized in dm_bufio_client_create, however, it is not destroyed before free the structure of dm_bufio_client in dm_bufio_client_destroy. Signed-off-by: Xiongwei Song --- drivers/md/dm-bufio.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [dm-devel] [for-4.16 PATCH v2 1/5] block: establish request failover callback

On Thu, Jan 04 2018 at 5:28am -0500, Christoph Hellwig wrote: > On Fri, Dec 29, 2017 at 03:19:04PM -0500, Mike Snitzer wrote: > > On Fri, Dec 29 2017 at 5:10am -0500, > > Christoph Hellwig wrote: > > > > > On Tue, Dec 26, 2017 at 10:22:53PM -0500, Mike Snitzer

Re: [dm-devel] [for-4.16 PATCH v2 0/5] block, nvme, dm: allow DM multipath to use NVMe's error handler

On Thu, Jan 04 2018 at 5:26am -0500, Christoph Hellwig wrote: > On Tue, Jan 02, 2018 at 04:29:43PM -0700, Keith Busch wrote: > > Instead of hiding NVMe path related errors, the NVMe driver needs to > > code an appropriate generic block status from an NVMe status. > > > > We

Re: [dm-devel] [for-4.16 PATCH v2 1/5] block: establish request failover callback

On Fri, Dec 29, 2017 at 03:19:04PM -0500, Mike Snitzer wrote: > On Fri, Dec 29 2017 at 5:10am -0500, > Christoph Hellwig wrote: > > > On Tue, Dec 26, 2017 at 10:22:53PM -0500, Mike Snitzer wrote: > > > All requests allocated from a request_queue with this callback set can > > >

Re: [dm-devel] [for-4.16 PATCH v2 0/5] block, nvme, dm: allow DM multipath to use NVMe's error handler

On Tue, Jan 02, 2018 at 04:29:43PM -0700, Keith Busch wrote: > Instead of hiding NVMe path related errors, the NVMe driver needs to > code an appropriate generic block status from an NVMe status. > > We already do this translation whether or not CONFIG_NVME_MULTIPATHING is > set, so I think it's