[dm-devel] [PATCH 2/4] libmultipath/discovery: modify NVMe path states
Hannes Reinecke
hare at suse.de
Fri Sep 15 11:06:21 UTC 2017
On 09/15/2017 12:00 PM, Guan Junxiong wrote:
>
>
> On 2017/9/15 14:30, Hannes Reinecke wrote:
>> The NVMe path states 'resetting' and 'reconnecting' indicate that
>> the controller could not talk to the namespace, which translates
>> into a path down state, not a path pending state.
>> Path pending should only be used for short lived intermediate states
>> like 'new' or 'deleting'.
> I agree with the statements --Path pending should only be used for short
> lived intermediate states. But it's better to schedule path state checking
> so soon as possible in the next second for "resetting" and "reconnecting"
> states because those two states is transient in a short time.
> How about introducing a new state for multipath: PATH_TRANSITING to distinguish
> PATH_PENDING?
>
I beg to disagree.
'reconnecting' is telling us that the controller is trying to reconnect
to the namespace, which will continue until KATO expires IIRC.
Which can well be several seconds, plus this actually _is_ a path down
state (path down signals that the transport layer lost connection to the
remote system, which is exactly what this error is).
And 'resetting' is the controller entering reset after KATO expired, so
most definitely a path down event.
And this took several minutes on the machine I've tested with, so it's
anything but fast.
Or to put it another way round: if we treat these events as
PATH_PENDING, which events would then signal a PATH_DOWN?
We only have
new
live
reconnecting
resetting
deleting
dead
to choose from ...
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare at suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
More information about the dm-devel
mailing list