On Tue, Oct 20, 2020 at 12:25:42AM +0530, 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. > > Benjamin, > Please let me know if iam wrong. You are correct. If a path is part of a multipath device, multipathd will run periodic checks on it. -Ben > > 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. > >
