From: Hannes Reinecke <hare@suse.de>
To: Nilay Shroff <nilay@linux.ibm.com>, Keith Busch <kbusch@kernel.org>
Cc: Hannes Reinecke <hare@kernel.org>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH] nvme: Remove namespace when nvme_identify_ns_descs() failed
Date: Mon, 13 Jan 2025 15:29:14 +0100 [thread overview]
Message-ID: <7aacb2fa-a7b9-4eb2-ad87-bdd24e1cd308@suse.de> (raw)
In-Reply-To: <c0f49aed-2f93-4b31-b768-e9e354c98d42@linux.ibm.com>
On 1/13/25 15:12, Nilay Shroff wrote:
>
>
> On 1/13/25 1:13 PM, Hannes Reinecke wrote:
>> On 1/11/25 15:01, Nilay Shroff wrote:
>>>
>>>
[ .. ]
>> So my argument is that in this specific case the 'ANA inaccessible' nvme
>> state should _not_ be retried, but should be treated as identical to
>> 'invalid namespace' errors.
>>
> I think I got what you're trying to propose. So when this issue manifests, on host, if we
> could possibly differentiate between nvme_identify_ns_descs() failed reasons : is it failed
> because the nsid has been removed/un-mapped on the target or is it failed due to "ANA inaccessible"
> state? IMO, for "ANA inaccessible" status, we may not want to immediately remove the ns from
> the host (due to reason I mentioned earlier per NVMe spec section 8.1.3.3), however for the
> other error case we may remove the ns from the host.
> I think issuing ns descriptor list command to target for a nsid which doesn't exist on the
> target would return buffer filled with all zeros. So that might be an indication that ns has
> been removed from the target.
>
But only if the NSID has not been remapped in the meantime.
If it has (as in my case) the ns descriptor list will be valid, it just
refers to another namespace.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2025-01-13 14:31 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-29 14:06 [PATCH] nvme: Remove namespace when nvme_identify_ns_descs() failed Hannes Reinecke
2024-12-03 19:15 ` Keith Busch
2024-12-04 7:14 ` Hannes Reinecke
2024-12-04 16:39 ` Keith Busch
2024-12-05 12:30 ` Hannes Reinecke
2024-12-05 16:15 ` Keith Busch
2024-12-06 12:41 ` Hannes Reinecke
2025-01-07 16:01 ` Keith Busch
2025-01-11 14:01 ` Nilay Shroff
2025-01-13 7:43 ` Hannes Reinecke
2025-01-13 14:12 ` Nilay Shroff
2025-01-13 14:29 ` Hannes Reinecke [this message]
2025-01-15 7:48 ` Nilay Shroff
2025-01-15 8:02 ` Hannes Reinecke
2025-01-15 8:18 ` Nilay Shroff
2025-01-15 8:22 ` Hannes Reinecke
2024-12-24 11:35 ` Sagi Grimberg
2024-12-25 9:58 ` Sagi Grimberg
2025-01-07 8:11 ` Hannes Reinecke
2025-01-08 10:49 ` Sagi Grimberg
2025-01-08 15:45 ` Hannes Reinecke
2025-01-10 23:16 ` Sagi Grimberg
2025-01-13 7:50 ` 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:
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=7aacb2fa-a7b9-4eb2-ad87-bdd24e1cd308@suse.de \
--to=hare@suse.de \
--cc=hare@kernel.org \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--cc=sagi@grimberg.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox