All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guan Junxiong <guanjunxiong@huawei.com>
To: Muneendra Kumar M <mmandala@Brocade.com>,
	Martin Wilck <mwilck@suse.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"christophe.varoqui@opensvc.com" <christophe.varoqui@opensvc.com>
Cc: "chengjike.cheng@huawei.com" <chengjike.cheng@huawei.com>,
	"niuhaoxin@huawei.com" <niuhaoxin@huawei.com>,
	"shenhong09@huawei.com" <shenhong09@huawei.com>
Subject: Re: [PATCH V4 1/2] multipath-tools: intermittent IO error accounting to improve reliability
Date: Tue, 19 Sep 2017 20:53:01 +0800	[thread overview]
Message-ID: <52829afa-ed9e-cc39-a492-3e678b8e0d03@huawei.com> (raw)
In-Reply-To: <8d45c076cf6c47d39bf2aade3ade7f51@BRMWP-EXMB12.corp.brocade.com>

Hi Muneendra ,
Thanks for your suggestion. My comments inline.

On 2017/9/19 18:59, Muneendra Kumar M wrote:
> Hi Guan/Martin,
> Below are my points.
> 
>>>> "san_path_double_fault_time"  is great.  One less additional parameter and still covering most scenarios are appreciated.
> This looks good and I completely agree with Guan.
> 
> One question san_path_double_fault_time is the time between two failed states (failed-active-failed )is this correct ?.
> Then this holds good.
> 
> Instead of san_path_double_fault_time can we call it as san_path_double_failed_time as the name suggests the time between two failed states is this ok ?
> 

Both names are fine for me.

> In SAN  topology (FC,NVME,SCSI)transient intermittent network errors make the ITL paths  as marginal paths. 
>
>
> So instead of calling "path_io_err_sample_time", "path_io_err_rate_threshold" and "path_io_err_recovery_time"
> can we name as "marginal_path_err_detection_time", " marginal_path_err_rate_threshold" and " marginal_path_err_recovery_time"
> 
> Some other names should also be good as the io_path is general word from my view.
> >

Can you explain "the marginal paths" in details?  Can the users easily catch the meaning of  marginal paths?
IMO, path_io_err_XXXs are easy to under_stand

> If we agree with this one more thing which I would like to add as part of this patch.
> 
> Whenever the path is in XXX_io_error_recovery_time  and if the user runs multipath -ll command the path the state of the path is shown as failed as shown below.
> 
> 	| `- 6:0:0:0 sdb 8:16  failed ready  running
> 
> Can we add a new state as marginal so that when the admin run the multipath command and found that the state is in marginal he can quickly come to know that this a marginal 
> Path and needs to be recovered .If we keep the state as failed the admin cannot understand from past how much time the device is in failed state.
> 
>

If the user use multipathd -k , then input "show paths", the multipathd will show the path in the state of "delayed".
But we can't find the exactly reason of the delayed state path because other features such as path waiting uses it.
Shall we use existing PATH_SHAKY ?

Regards.
Guan

  reply	other threads:[~2017-09-19 12:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-17  3:40 [PATCH V4 0/2] multipath-tools: intermittent IO error accounting to improve reliability Guan Junxiong
2017-09-17  3:40 ` [PATCH V4 1/2] " Guan Junxiong
2017-09-18 12:53   ` Muneendra Kumar M
2017-09-18 14:36     ` Guan Junxiong
2017-09-18 19:51       ` Martin Wilck
2017-09-19  1:32         ` Guan Junxiong
2017-09-19 10:59           ` Muneendra Kumar M
2017-09-19 12:53             ` Guan Junxiong [this message]
2017-09-20 12:58               ` Muneendra Kumar M
2017-09-21 10:04                 ` Guan Junxiong
2017-09-21 10:10                   ` Muneendra Kumar M
     [not found]                   ` <615cdd5a955944e49986dca01bf406a5@BRMWP-EXMB12.corp.brocade.com>
2017-10-09  0:42                     ` Guan Junxiong
2017-10-09 11:39                       ` Muneendra Kumar M
2017-10-12  6:35                       ` Muneendra Kumar M
2017-10-12  6:46                         ` Guan Junxiong
2017-10-12  6:59                           ` Muneendra Kumar M
2017-09-17  3:40 ` [PATCH V4 2/2] multipath-tools: discard san_path_err_XXX feature Guan Junxiong

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=52829afa-ed9e-cc39-a492-3e678b8e0d03@huawei.com \
    --to=guanjunxiong@huawei.com \
    --cc=chengjike.cheng@huawei.com \
    --cc=christophe.varoqui@opensvc.com \
    --cc=dm-devel@redhat.com \
    --cc=mmandala@Brocade.com \
    --cc=mwilck@suse.com \
    --cc=niuhaoxin@huawei.com \
    --cc=shenhong09@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.