On 01/03/2018 12:29 AM, 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 silly NVMe native
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
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
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
On Tue, Jan 02 2018 at 6:29pm -0500,
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
>
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 silly NVMe native multipathing has a second status
decoder. This just
This v2 follows Keith's suggestion to only add a 'failover_rq_fn' to
the request_queue (rather than both the bio and request structs).
Jens or Christoph, provided review is favorable, I'd very much
appreciate it you'd pick up patches 1 - 3 for 4.16.
These patches enable DM multipath to work well