[PATCH] nvme-core: update NS Attr Changed AEN handling for ANA group

Knight, Frederick Frederick.Knight at netapp.com
Tue Dec 8 19:07:08 EST 2020


If you want to make that a transition, then bring a TPAR to change it.

When ANA Groups are created, they already have a state.  There is NO transition; there is NO AEN.

	Fred

-----Original Message-----
From: Keith Busch <kbusch at kernel.org> 
Sent: Tuesday, December 8, 2020 4:47 PM
To: Knight, Frederick <Frederick.Knight at netapp.com>
Cc: hch at lst.de; Meneghini, John <John.Meneghini at netapp.com>; George, Martin <Martin.George at netapp.com>; linux-nvme at lists.infradead.org; sagi at grimberg.me; Hannes Reinecke <hare at suse.com>
Subject: Re: [PATCH] nvme-core: update NS Attr Changed AEN handling for ANA group

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.




On Tue, Dec 08, 2020 at 07:13:00PM +0000, Knight, Frederick wrote:
> Setting up a new ANA Group does NOT cause a transition from <UNKNOWN state> to <some known state>.  The establishment of initial state is NOT a change of state as defined in section 8.20.3.6.
>
> An ANA AEN is prohibited if the ANA change is due to the creation of a namespace.

Yes, the AEN is prohibited if the ANA change is due to the creation of a namespace. In this scenario, though, the ANA change is due to a group entering a state, and you're required to notify that as long as ANA events are enabled. There is no text in section 8.20.3.6 or anywhere else that I can find that says creating a group with a valid state disqualifies it as "entering" that state. However, I do find that section 8.20.3.5 says transitions may occur from states not visible to the host, so <UNKNOWN state> to <known state> is a transition according to the spec.



More information about the Linux-nvme mailing list