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? PATH_TRANSITING should also schedule path state checking so soon as possible in the next second. Thanks Guan > Signed-off-by: Hannes Reinecke <hare@xxxxxxxx> > --- > libmultipath/discovery.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c > index 95c138b..a880f4b 100644 > --- a/libmultipath/discovery.c > +++ b/libmultipath/discovery.c > @@ -1449,8 +1449,7 @@ path_offline (struct path * pp) > } > pp->offline = 0; > if (!strncmp(buff, "new", 3) || > - !strncmp(buff, "reconnecting", 12) || > - !strncmp(buff, "resetting", 9)) > + !strncmp(buff, "deleting", 8)) > return PATH_PENDING; > else if (!strncmp(buff, "live", 4)) > return PATH_UP; > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
