All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagi@grimberg.me>
To: Victor Gladkov <Victor.Gladkov@kioxia.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Cc: James Smart <james.smart@broadcom.com>,
	"Ewan D. Milne" <emilne@redhat.com>,
	Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH v8] nvme-fabrics: reject I/O to offline device
Date: Tue, 29 Sep 2020 01:10:15 -0700	[thread overview]
Message-ID: <947945e1-6aee-231c-20c1-f0bb6b2d7195@grimberg.me> (raw)
In-Reply-To: <f9188630aec6471e8cf6ab9d3f1cf989@kioxia.com>


>>> diff --git a/drivers/nvme/host/multipath.c
>>> b/drivers/nvme/host/multipath.c index 54603bd..d8b7f45 100644
>>> --- a/drivers/nvme/host/multipath.c
>>> +++ b/drivers/nvme/host/multipath.c
>>> @@ -278,9 +278,12 @@ static bool nvme_available_path(struct
>>> nvme_ns_head *head)
>>>
>>>    	list_for_each_entry_rcu(ns, &head->list, siblings) {
>>>    		switch (ns->ctrl->state) {
>>> +		case NVME_CTRL_CONNECTING:
>>> +			if (test_bit(NVME_CTRL_FAILFAST_EXPIRED,
>>> +				     &ns->ctrl->flags))
>>> +				break;
>>>    		case NVME_CTRL_LIVE:
>>>    		case NVME_CTRL_RESETTING:
>>> -		case NVME_CTRL_CONNECTING:
>>>    			/* fallthru */
>>>    			return true;
>>>    		default:
>>
>> This is too subtle to not document.
>> The parameter is a controller property, but here it will affect the mpath device
>> node.
>>
>> This is changing the behavior of "queue as long as we have an available path"
>> to "queue until all our paths said to fail fast".
>>
>> I guess that by default we will have the same behavior, and the behavior will
>> change only if all the controller have failfast parameter tuned.
>>
>> At the very least it is an important undocumented change that needs to be
>> called in the change log.
> 
> The multipath may be stuck on reconnected controller even forever.
> Moreover, all commands will be returned with error status,
> but the path will not be switched.
> And in this case, the presence of the additional path looks pointless.

Its not pointless, currently while there is an available path that may
become active we queue it up. Your suggestion to fail multipath commands
when the last failfail timeout expires is OK, but must be documented.

> I suggest use the failfast parameter for each path separately.

It is already a controller attribute.

> It can also serve as the priority of each path.

Lets not do anything on that front, if someone wants fail certain
controllers faster than others, he can do it, but nothing should
be mandated from the driver for sure...

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

      reply	other threads:[~2020-09-29  8:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-07  6:21 [PATCH v8] nvme-fabrics: reject I/O to offline device Victor Gladkov
2020-09-18 20:38 ` Sagi Grimberg
2020-09-27  6:04   ` Christoph Hellwig
2020-09-27 11:48   ` Victor Gladkov
2020-09-29  8:10     ` Sagi Grimberg [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=947945e1-6aee-231c-20c1-f0bb6b2d7195@grimberg.me \
    --to=sagi@grimberg.me \
    --cc=Victor.Gladkov@kioxia.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=james.smart@broadcom.com \
    --cc=linux-nvme@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.