On Tue, Feb 14 2017 at 6:00pm -0500,
Keith Busch <keith.busch@xxxxxxxxx> 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 devices are mulitpath capable, and have been able to stack with
> > > dm-mpath since kernel 4.2.
> > >
> > > - str = STRDUP("^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk|nvme)[0-9]");
> > > + str = STRDUP("^(ram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0-9]");
> >
> > Have you checked whether dm-mpath works properly with nvme? Last time I
> > tried that dm-mpath crashed when it called scsi_dh_attach() because that
> > last function assumes that it is passed a SCSI device queue instead of
> > checking whether or not the queue passed to that function is a SCSI
> > device queue.
>
> Good point. I was unknowingly running with CONFIG_SCSI_DH disabled,
> and blissfully unaware of its existence! After enabling that option,
> I see what you mean.
>
> If we don't want to mess with the kernel, I can change the multipath-tools
> to get around that by appending the following to NVMe hwentry in the
> second patch in this series:
>
> .retain_hwhandler = RETAIN_HWHANDLER_OFF,
>
> And the problem goes away.
That gives me a clue, I'll take a look.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
