Brian, On Thu, 2023-03-09 at 13:40 -0800, Brian Bunker wrote: > > Martin, > > Sorry I bounce between kernel versions a lot since most of the > problems which find their way to us are released Linux versions > whose kernels are quite a bit older than upstream.I got a chance > to try the proposed solutions. The PATH_GHOST above does what > I am looking for which is not to have the path checker fail the path. > > This also works as your earlier comments suggest. This does seem > clearer as to what is happening on the path: > I apologize for being slow, but I don't quite understand this response. Have you tested Ben's patch set? Does it work for you? Is the patch below meant to be applied on top of Ben's work? Martin > diff --git a/libmultipath/checkers.c b/libmultipath/checkers.c > index fdb91e17..50f0773e 100644 > --- a/libmultipath/checkers.c > +++ b/libmultipath/checkers.c > @@ -343,6 +343,7 @@ static const char > *generic_msg[CHECKER_GENERIC_MSGTABLE_SIZE] = { > [CHECKER_MSGID_UP] = " reports path is up", > [CHECKER_MSGID_DOWN] = " reports path is down", > [CHECKER_MSGID_GHOST] = " reports path is ghost", > + [CHECKER_MSGID_PENDING] = " reports path is transitioning", > [CHECKER_MSGID_UNSUPPORTED] = " doesn't support this device", > }; > > diff --git a/libmultipath/checkers.h b/libmultipath/checkers.h > index ea1e8af6..4fbad621 100644 > --- a/libmultipath/checkers.h > +++ b/libmultipath/checkers.h > @@ -111,6 +111,7 @@ enum { > CHECKER_MSGID_UP, > CHECKER_MSGID_DOWN, > CHECKER_MSGID_GHOST, > + CHECKER_MSGID_PENDING, > CHECKER_MSGID_UNSUPPORTED, > CHECKER_GENERIC_MSGTABLE_SIZE, > CHECKER_FIRST_MSGID = 100, /* lowest msgid for checkers > */ > > diff --git a/libmultipath/checkers/tur.c > b/libmultipath/checkers/tur.c > index 551dc4f0..e1742c2b 100644 > --- a/libmultipath/checkers/tur.c > +++ b/libmultipath/checkers/tur.c > @@ -179,7 +179,7 @@ retry: > else if (key == 0x2) { > /* Not Ready */ > /* Note: Other ALUA states are either UP or > DOWN */ > - if( asc == 0x04 && ascq == 0x0b){ > + if (asc == 0x04 && ascq == 0x0b) { > /* > * LOGICAL UNIT NOT ACCESSIBLE, > * TARGET PORT IN STANDBY STATE > @@ -187,6 +187,14 @@ retry: > *msgid = CHECKER_MSGID_GHOST; > return PATH_GHOST; > } > + if (asc == 0x04 && ascq == 0x0a) { > + /* > + * LOGICAL UNIT NOT ACCESSIBLE, > + * TARGET PORT IN TRANSITION STATE > + */ > + *msgid = CHECKER_MSGID_PENDING; > + return PATH_PENDING; > + } > } > *msgid = CHECKER_MSGID_DOWN; > return PATH_DOWN; > > This change also keeps the path from being failed by the checker. > It seems to go into and out of transitioning from other states. > > Thanks, > Brian > > > > > > > > > > The default transitioning timeout is 60s, and in my experience, > > > > even if > > > > the hardware overrides it, it's rarely more than a few minutes. > > > > After > > > > that, the kernel will set the state to STANDBY. > > > Yes. The case of a target keeping a path in the transitioning > > > state > > > Indefinitely is handled by the device handler. > > > > > > > > Unless we're both overlooking something, I agree with you that > > > > PATH_PENDING is the right thing to do for TRANSITIONING. When a > > > > device > > > > is in transition between states, we _want_ to check it often to > > > > make > > > > sure we notice when the target state is reached. > > > > > > > > We must then be careful not to overload PATH_PENDING with too > > > > many > > > > different meanings. But I don't see this as a big issue > > > > currently. > > > > > > > > Regards > > > > Martin > > > > > > > > > Thoughts? > > > > > > > > > > -Ben > > > > > > > > > > > > > > > > > Regards > > > > > > Martin > > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel