[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