[PATCH 5/8] nvme: sync the namespace scanning during ctrl start

Max Gurtovoy mgurtovoy at nvidia.com
Mon Jan 29 04:37:52 PST 2024



On 29/01/2024 12:48, Sagi Grimberg wrote:
> 
>>>> Even in this case of re-creation we must sync the namespace 
>>>> identification.
>>>
>>> But a format is not a re-creation.
>>>
>>
>> we currently don't support format in fabrics so maybe I didn't use the 
>> correct word during my answer.
>>
>> because of the dynamic nature of controllers and namespaces we have 
>> the identify ctrl/ns commands in the specification and we need to use 
>> them.
> 
> ns scanning has been notorious to cause issues when executing with
> controller resets. So I don't think it is a good idea to make ctrl start
> block until it completes, especially not for an esoteric case that
> a ns that suddenly was reformatted between reconnects.
> 

I think that making sure that the namespace is active and validated is 
not esoteric.
What is the concern ? is it the time it takes to validate a namespace ?

>> Re-queue requests to a non identified namespace is bad behavior. It 
>> might be even a spec violation (I need to dig into the spec for it 
>> probably and try to find some description on that scenario).
> 
> It can't be a spec violation, the host cannot know if there is any
> aen pending (for example NS_CHANGE) when sending *ANY* command to the
> controller.

I think that AEN and reset flows are a bit different. The controller is 
free to be modified at any time (even when no Admin queue is opened from 
the host). It may have out-of-band management interface (for example the 
nvmet cli) and may not have any association (AQ) to the host to notify 
on changes.



More information about the Linux-nvme mailing list