public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Muneendra Kumar M <muneendra.kumar@broadcom.com>
To: Hannes Reinecke <hare@suse.de>,
	Michael Christie <michael.christie@oracle.com>
Cc: linux-scsi@vger.kernel.org, jsmart2021@gmail.com,
	emilne@redhat.com, mkumar@redhat.com
Subject: RE: [PATCH v3 05/17] scsi_transport_fc: Added a new rport state FC_PORTSTATE_MARGINAL
Date: Mon, 19 Oct 2020 23:33:03 +0530	[thread overview]
Message-ID: <e031f239c4bc02cafde13ad573523559@mail.gmail.com> (raw)
In-Reply-To: bf347ae232d73c4a21af6514085a92f2@mail.gmail.com

[-- Attachment #1: Type: text/plain, Size: 2220 bytes --]

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.
Hannes/James Correct me if this is wrong.

Regards,
Muneendra.

-----Original Message-----
From: Muneendra Kumar M [mailto:muneendra.kumar@broadcom.com]
Sent: Monday, October 19, 2020 11:01 PM
To: 'Hannes Reinecke' <hare@suse.de>; 'Michael Christie'
<michael.christie@oracle.com>
Cc: 'linux-scsi@vger.kernel.org' <linux-scsi@vger.kernel.org>;
'jsmart2021@gmail.com' <jsmart2021@gmail.com>; 'emilne@redhat.com'
<emilne@redhat.com>; 'mkumar@redhat.com' <mkumar@redhat.com>
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.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4177 bytes --]

  parent reply	other threads:[~2020-10-19 18:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  3:27 [PATCH v3 00/17] scsi: Support to handle Intermittent errors Muneendra
2020-10-15  3:27 ` [PATCH v3 01/17] scsi: Added a new definition in scsi_cmnd.h Muneendra
2020-10-15  3:27 ` [PATCH v3 02/17] scsi: Added a new error code in scsi.h Muneendra
2020-10-15  3:27 ` [PATCH v3 03/17] scsi: No retries on abort success Muneendra
2020-10-16 18:37   ` Mike Christie
2020-10-19 19:05   ` Mike Christie
2020-10-19 19:26     ` Muneendra Kumar M
2020-10-20 19:53       ` Mike Christie
2020-10-20 20:18         ` Mike Christie
2020-10-21 18:51           ` Muneendra Kumar M
2020-10-15  3:27 ` [PATCH v3 04/17] scsi: Added routine to set/clear SCMD_NORETRIES_ABORT bit for outstanding io on scsi_dev Muneendra
2020-10-15  3:27 ` [PATCH v3 05/17] scsi_transport_fc: Added a new rport state FC_PORTSTATE_MARGINAL Muneendra
2020-10-16 19:52   ` Mike Christie
2020-10-19 10:47     ` Muneendra Kumar M
2020-10-19 16:10       ` Michael Christie
2020-10-19 16:19         ` Michael Christie
2020-10-19 17:16           ` Hannes Reinecke
2020-10-19 17:31             ` Muneendra Kumar M
2020-10-19 18:55               ` Mike Christie
2020-10-19 19:03                 ` Muneendra Kumar M
2020-10-20 18:24                   ` Benjamin Marzinski
2020-10-20  6:03                 ` Hannes Reinecke
2020-10-19 18:03             ` Muneendra Kumar M [this message]
2020-10-19 18:44               ` Mike Christie
2020-10-19 18:55                 ` Muneendra Kumar M
2020-10-20 16:48                   ` Mike Christie
2020-10-20 17:19                     ` Muneendra Kumar M
2020-10-20 18:44                       ` Benjamin Marzinski
2020-10-20 18:14                   ` Benjamin Marzinski
2020-10-15  3:27 ` [PATCH v3 06/17] scsi_transport_fc: Added store fucntionality to set the rport port_state using sysfs Muneendra
2020-10-15 14:05   ` kernel test robot
2020-10-16 18:34   ` Mike Christie
2020-10-19 10:52     ` Muneendra Kumar M
2020-10-15  3:27 ` [PATCH v3 07/17] scsi:lpfc: Added changes to fc_remote_port_chkready Muneendra
2020-10-15  3:27 ` [PATCH v3 08/17] scsi:qla2xx: " Muneendra
2020-10-15  3:27 ` [PATCH v3 09/17] scsi:qedf: " Muneendra
2020-10-15  3:27 ` [PATCH v3 10/17] scsi:libfc: " Muneendra
2020-10-15  3:27 ` [PATCH v3 11/17] scsi:ibmvfc: " Muneendra
2020-10-15  3:27 ` [PATCH v3 12/17] scsi:fnic: " Muneendra
2020-10-15  3:27 ` [PATCH v3 13/17] scsi:bnx2fc: " Muneendra
2020-10-15  3:27 ` [PATCH v3 14/17] scsi:csio: " Muneendra
2020-10-15  3:27 ` [PATCH v3 15/17] scsi:bfa: " Muneendra
2020-10-15  3:27 ` [PATCH v3 16/17] scsi:zfcp: " Muneendra
2020-10-22 16:50   ` Benjamin Block
2020-10-15  3:27 ` [PATCH v3 17/17] scsi:mpt: " Muneendra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e031f239c4bc02cafde13ad573523559@mail.gmail.com \
    --to=muneendra.kumar@broadcom.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=jsmart2021@gmail.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michael.christie@oracle.com \
    --cc=mkumar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox