Re: [PATCH] [PATCH] libmultipath: return 'ghost' state when port is in transition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux