All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Uday Shankar <ushankar@purestorage.com>
Cc: linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
	Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
	Jens Axboe <axboe@fb.com>
Subject: Re: [PATCH] nvme: scan sequentially only when list scan unsupported
Date: Mon, 7 Nov 2022 06:56:05 +0100	[thread overview]
Message-ID: <20221107055605.GF28873@lst.de> (raw)
In-Reply-To: <20221104223621.1435666-1-ushankar@purestorage.com>

On Fri, Nov 04, 2022 at 04:36:22PM -0600, Uday Shankar wrote:
> Currently, if nvme_scan_ns_list fails, nvme_scan_work will fall back to
> a sequential scan. nvme_scan_ns_list can fail for a variety of reasons,
> e.g. transient transport issue. And the resulting sequential scan can be
> extremely expensive on controllers reporting an NN value close to the
> maximum allowed (>4 billion). Avoid sequential scans wherever possible
> by only falling back to them if nvme_scan_ns_list fails due to
> controller non-support of Identify NS List.
> ---
> This would break devices that claim to support version NVME_VS(1, 1, 0)
> or above, but don't support Identify NS List. But it looks like we
> already have NVME_QUIRK_IDENTIFY_CNS to deal with that.

Yes.  I'm a little worried about changing something this fundamental
after such a long time, even if it is the right thing to do.  But at
least we get a warning when the Identify NS List fails, so between
that and the fact tht nvme_scan_ns_list logs an error I think we can
cope.

>  	mutex_lock(&ctrl->scan_lock);
> -	if (nvme_scan_ns_list(ctrl) != 0)
> +	if (nvme_scan_ns_list(ctrl) == -EOPNOTSUPP)
>  		nvme_scan_ns_sequential(ctrl);

Maybe make this a bit more clear by lifting the nvme_ctrl_limited_cns
check into nvme_scan_work, though:

	if (nvme_ctrl_limited_cns(ctrl))
		nvme_scan_ns_sequential(ctrl);
	else
		nvme_scan_ns_list(ctrl);

and drop the now superflous error return from nvme_scan_ns_list.


  parent reply	other threads:[~2022-11-07  5:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04 22:36 [PATCH] nvme: scan sequentially only when list scan unsupported Uday Shankar
2022-11-04 22:46 ` Uday Shankar
2022-11-07  5:56 ` Christoph Hellwig [this message]
2022-11-07 19:29   ` Uday Shankar

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=20221107055605.GF28873@lst.de \
    --to=hch@lst.de \
    --cc=axboe@fb.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    --cc=ushankar@purestorage.com \
    /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.