Linux-NVME Archive on
 help / color / Atom feed
From: Sagi Grimberg <>
To: Hannes Reinecke <>, Christoph Hellwig <>
Cc: Keith Busch <>,,
	John Managhini <>
Subject: Re: [PATCH] nvme-multipath: do not reset controller on unknown status
Date: Wed, 12 Feb 2020 23:19:40 -0800
Message-ID: <> (raw)
In-Reply-To: <>

>> What will happen in the common case? right now it will just retry
>> it on the same path, is that the desired behavior?
>> I guess we need to understand the phenomenon better.
>> Right now the code says, we don't know what went wrong here, so we
>> are going to reset the controller because it acts weird, which can
>> make some sense, given that the host doesn't understand what is going
>> on...
> But this is precisely the case I'm arguing against here.
> One of the lessons learned from SCSI is that reset only makes sense if
> the system misbehaves and resetting it would make this error go away.
> Receiving a status code which we don't know about does _not_ fall into
> this category; the very fact that we have a status code proves that the
> system does _not_ misbehave.

Fair enough...

> So what exactly will be resolved by resetting?
> There actually is a fair chance that we'll be getting the very same
> error again...

Or not, we don't know.. That is exactly the point.. But I agree with
you that resetting the controller may not the best action to take here.

But, you didn't answer my question, what is the expected behavior here?
right now with your patch is to blindly retry on the same path, is that
desired? is that always desired? Please share more details on the issue.

> Consequently I think that resetting the system here is wrong, and we
> should just handle it as a normal but unknown error.

What is this unknown error? Was it what John complained about a few
months back that the array returned a status code that translated
to BLK_STS_IOERR which is considered a path error and the host reset
the controller?

I think I'm starting to remember that this sort of approach was
suggested... I forget the details though...

linux-nvme mailing list

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12 13:41 Hannes Reinecke
2020-02-12 17:53 ` Christoph Hellwig
2020-02-12 19:33   ` Sagi Grimberg
2020-02-13  7:02     ` Hannes Reinecke
2020-02-13  7:19       ` Sagi Grimberg [this message]
2020-02-13 17:02       ` Keith Busch
2020-02-14 14:22         ` Meneghini, John
2020-02-19 15:03           ` Christoph Hellwig
2020-02-13  6:53   ` Hannes Reinecke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-NVME Archive on

Archives are clonable:
	git clone --mirror linux-nvme/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nvme linux-nvme/ \
	public-inbox-index linux-nvme

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone