On 10/19/20 1:55 PM, Muneendra Kumar M wrote:
Hi Micheal,
AFIK As long as the paths are available irrespective of the path is moved
to marginal path group or not multipathd will keep sending the send path
tester IO (TUR) to check the health status.
You can change the multipathd code.
Benjamin,
Please let me know if iam wrong >
Regards,
Muneendra.
-----Original Message-----
From: Mike Christie [mailto:michael.christie@xxxxxxxxxx]
Sent: Tuesday, October 20, 2020 12:15 AM
To: Muneendra Kumar M <muneendra.kumar@xxxxxxxxxxxx>; Hannes Reinecke
<hare@xxxxxxx>
Cc: linux-scsi@xxxxxxxxxxxxxxx; jsmart2021@xxxxxxxxx; emilne@xxxxxxxxxx;
mkumar@xxxxxxxxxx
Subject: Re: [PATCH v3 05/17] scsi_transport_fc: Added a new rport state
FC_PORTSTATE_MARGINAL
On 10/19/20 1:03 PM, Muneendra Kumar M wrote:
Hi Michael,
Regarding the TUR (Test Unit Ready)command which I was mentioning .
Multipath daemon issues TUR commands on a regular intervals to check
the path status.
When a port_state is set to marginal we are not suppose to end up
failing the cmd with DID_TRANSPORT_MARGINAL with out proceeding it.
This may leads to give wrong health status.
If your daemon works such that you only move paths from marginal to active
if you get an ELS indicating the path is ok or you get a link up, then why
have multipathd send path tester IO to the paths in the marginal path group?
They do not do anything do they?
Hannes/James Correct me if this is wrong.
Regards,
Muneendra.
-----Original Message-----
From: Muneendra Kumar M [mailto:muneendra.kumar@xxxxxxxxxxxx]
Sent: Monday, October 19, 2020 11:01 PM
To: 'Hannes Reinecke' <hare@xxxxxxx>; 'Michael Christie'
<michael.christie@xxxxxxxxxx>
Cc: 'linux-scsi@xxxxxxxxxxxxxxx' <linux-scsi@xxxxxxxxxxxxxxx>;
'jsmart2021@xxxxxxxxx' <jsmart2021@xxxxxxxxx>; 'emilne@xxxxxxxxxx'
<emilne@xxxxxxxxxx>; 'mkumar@xxxxxxxxxx' <mkumar@xxxxxxxxxx>
Subject: RE: [PATCH v3 05/17] scsi_transport_fc: Added a new rport
state FC_PORTSTATE_MARGINAL
Hi Michael,
Oh yeah, to be clear I meant why try to send it on the marginal path
when you are setting up the path groups so they are not used and only
the optimal paths are used.
When the driver/scsi layer fails the IO then the multipath layer will
make sure it goes on a optimal path right so you do not have to worry
about hitting a cmd timeout and firing off the scsi eh.
However, one other question I had though, is are you setting up
multipathd so the marginal paths are used if the optimal ones were to
fail (like the optimal paths hit a link down, dev_loss_tmo or
fast_io_fail fires, etc) or will they be treated like failed paths?
So could you end up with 3 groups:
1. Active optimal paths
2. Marginal
3. failed
If the paths in 1 move to 3, then does multipathd handle it like a
all paths down or does multipathd switch to #2?
Actually, marginal path work similar to the ALUA non-optimized state.
Yes, the system can sent I/O to it, but it'd be preferable for the
I/O to be moved somewhere else.
If there is no other path (or no better path), yeah, tough.
Hence the answer would be 2)
[Muneendra]As Hannes mentioned if there are no active paths, the
marginal paths will be moved to normal and the system will send the io.
Regards,
Muneendra.
