[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