[PATCH] nvme-multipath: add an 'ana_groups_only' module option

Hannes Reinecke hare at suse.de
Mon Feb 7 05:00:53 PST 2022


On 2/7/22 13:37, Sagi Grimberg wrote:
> 
>> On large installations the ANA log buffer can be exceedingly large;
>> we've come across a controller with 49 ANA Group Descriptors and
>> 65536 namespaces, resulting in an ANA buffer with an order-7 allocation.
>> And this is just to validate that the namespace ID is _really_listed
>> in the log page.
>> So to avoid an overly large memory allocation we can leverage the
>> 'RGO' bit when retrieving the ANA log page, and check whether the
>> ANA group ID from the namespace is found in the ANA descriptors.
>> That cuts down the memory allocation, and provides the same result.
>> But to be on the safe side I've added a module option 'ana_groups_only'
>> to switch between modes.
> 
> Hannes, why not a sysfs writable attribute? One can add a udev rule if
> it wants a one-shot all controllers...
> 
'tis a bit late, innit?
By the time we manage to write to the sysfs attribute (which, out of 
necessity, will be a controller attribute) the controller is already 
present, and the ANA log will already be read ...

> Although maybe that will bring us to yet another attribute that is
> unstable until the controller identifies...
> 
Yep.

> I think we are getting more indication that the controller device
> creation is sitting in the wrong place...

As mentioned earlier: main problem is that we need the controller device 
to initiate a controller removal. And as there is a possibility that the 
device initialisation _itself_ goes wrong we might need to tear down the
controller even before initialisation is done.
Which currently requires the sysfs attribute.
If we manage to figure out how to do that without the sysfs attribute
we should be fine.

Not that it'll help us in this case, though.
The only way out of _this_ issue is to pass in the configuration for
controller setup, ie adding a new argument to the fabrics configuration 
(eg 'ana_groups_only=1' or somesuch).
But I'm not sure if we want to go that way ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer



More information about the Linux-nvme mailing list