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

[Knight, Frederick]

We can't send the AEN if we create the ANA Group before creating the namespace - because there is no attached NS to which we can send the AER.  And, we can't create a namespace in an ANA group unless the ANA group already exists.

OK, here is the text you are quoting:
8.20.3.6	Asymmetric Namespace Access Change Notifications
If Asymmetric Namespace Access Change Notices are enabled (refer to section 5.21.1.11) on a controller, then an Asymmetric Namespace Access Change Notice shall be sent by the controllers where the change occurred:
a)	if an ANA Group Identifier (refer to Figure 251) changes;
b)	if an asymmetric namespace access state transition fails (e.g., a transition begins, but does not complete and the controller returns to the state that existed before the transition began); or
c)	upon entry to the following ANA states:
•	ANA Optimized State;
•	ANA Non-Optimized State;
•	ANA Inaccessible State; and
•	ANA Persistent Loss State.

So, what you're saying is that storage determining the initial state is a TRANSITION.  So that would also mean that after every connection, you would get a FLOOD of ANA Changed AENs as we discover the initial state of each ANA group, and TRANSITION that group from <unknown> to optimized state (or one of those 4 states).

That honestly makes no sense.  You really want all those AENs every time you connect to a new controller?

Discovery by the host of a new namespace should be the same if it happens at boot, or it happens later when a new namespace is discovered.  It seems like you're asking for 2 different discovery processes.  For some period after a new connection, you don't want the AENs telling you the ANA group entered its initial state, but after that time is up, then you DO want AENs to tell you when an ANA group enters its initial state.

The text never mentions anything about changes to "Number of ANA Group Descriptors" field and any relationship with the AEN, so I have no idea where you're getting that from.  The text does explicitly say that if the ANA changes was due to the creation of a namespace - if the ANA log pages changes because of a namespace being created, then there is NO AEN for that change.

A controller shall not send this event if:
a)	the change is due to the creation of a namespace (refer to section 5.20); or
b)	the change is due to the deletion of a namespace (refer to section 5.20),

	Fred

-----Original Message-----
From: Keith Busch <kbusch at kernel.org> 
Sent: Tuesday, December 8, 2020 12:41 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 03:21:16PM +0000, Knight, Frederick wrote:
> It is clear that the NS attribute change is required:
> Namespace Attribute Changed: Indicates a change to one or both of the following:
> •     ... ; or
> •     the Namespace List returned when the Identify command is issued with the CNS field set to 02h.
>
> It seems clear to me that the ANA change IS prohibited:
>
> Asymmetric Namespace Access Change: The Asymmetric Namespace Access 
> information (refer to section 5.14.1.12) related to an ANA Group that 
> contains namespaces attached to this controller has changed (e.g., an 
> ANA state has changed, an ANAGRPID has changed). The current 
> Asymmetric Namespace Access information for attached namespaces is 
> indicated in the Asymmetric Namespace Access log page (refer to 
> section 5.14.1.12).
>
> We CANNOT deliver this AEN unless it is related to an ANA group that 
> contains namespaces attached to this controller.  The creating of a 
> new ANA group (which therefore has no namespaces) does not meet the 
> criteria of "containing namespaces attached to this controller".  So 
> there are 2 possible orders - 1) the ANA group is created before the 
> namespace, or 2) the namespace is created before the namespace.  If 
> the Group is created before the namespace, then there are NO attached 
> namespaces in that (brand new) ANA group, therefore, we are prohibited 
> from sending the AEN.  If the namespace is created before the ANA 
> group, then we hit the next language, that prohibits sending the ANA 
> changed AEN because is it "due to the creation of a namespace".

It can't be "1". If you make a group without a namespace, the host couldn't read it anyway because the log only contains entries for groups with namespaces attached to that controller.

As for "2", my understanding from reading this is that it refers to suppressing the ANA event when a change in the "Number of NSID Values"
within a group occurs rather than a change in "Number of ANA Group Descriptors" field.

As for text supporting it, we have 8.20.3.6:

  an Asymmetric Namespace Access Change Notice shall be sent by the
  controllers where the change occurred:
   ...
  c) upon entry to the following ANA states:

Your scenario has an ANA group that previously didn't exist entering a state, so you shall send the event.