On Tue, Oct 20, 2020 at 10:49:56PM +0530, Muneendra Kumar M wrote: > HI Michael, > > > 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. > You mean to say don't send the TUR commands for the devices under marginal > path groups ? Multipath does need to keep checking the marginal paths. For one thing, just because a path is marginal, doesn't mean it belongs in the same path group as every other marginal path. If you have an active/passive array, then it's quite possible that you will have multiple marginal path groups. A path's priority is updated when it is checked, and many devices use this to determine the correct path groups. Also the checker is what determines if a path is in a ghost (passive) state, which tells multipath which path group to try next. For another thing, if all the non-marginal paths fail, then the marginal path group will also be the active path group, and we definitely want to be checking the paths on the active path group. -Ben > > At present the multipathd checks the device state. If the device state is > "running" then the check_path > Will issue a TUR commands at regular intervals to check the path health > status. > > 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. > >>
