From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.garry@huawei.com>, <martin.petersen@oracle.com>,
<jejb@linux.vnet.ibm.com>
Cc: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<zhaohongjiang@huawei.com>, <hare@suse.com>,
<dan.j.williams@intel.com>, <jthumshirn@suse.de>, <hch@lst.de>,
<huangdaode@hisilicon.com>, <chenxiang66@hisilicon.com>,
<xiexiuqi@huawei.com>, <tj@kernel.org>, <miaoxie@huawei.com>,
Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH 4/8] scsi: libsas: trigger a new revalidation to discover the device
Date: Mon, 4 Jun 2018 09:01:38 +0800 [thread overview]
Message-ID: <5B148F72.3000000@huawei.com> (raw)
In-Reply-To: <6b030b96-9733-f6b5-e8af-d1d488c52fb4@huawei.com>
On 2018/6/1 18:02, John Garry wrote:
> I mean that since libsas does disocovery/revalidation for all expander
> PHYS for a single event, than all discovery/revalidation should be
> synchronised with that same event. I don't mean that for a given
> expander PHY which originated a broadcast event, the
> revalidation/discovery for that PHY should be synchronised with that
> same event. Like you said, I don't think it's possible.
>
> On another point, one of the reasons to synchronise event processing was
> so events are not lost and are processed in order. In principle, by
> chaining these bcast events we lose that, since other PHY events may be
> queued before we queue the new artificial bcast events.
>
I got what you mean. I will try to keep the principle of synchronised
event processing.
>>
>> But if you mean we shall do this device removing and rediscovering in
>> one revalidation if it is not a "flutter", I think we can wrap a new
>> function for sas_revalidate_domain(), such as:
>>
>>
>> while (need_to_revalidate_again)
>> need_to_revalidate_again = sas_revalidate_domain()
>>
>> In this way the sas_port adding/removing is packed in one loop, we won't
>> have the annoyance of "duplicate filename" warning. What do you
>> think?
>
> Something like that, where all the discovery/revalidation and related
> device + port processing is done before we complete the revalidation
> event processing. A single revalidation event may defer do device+port
> processing multiple times.
WARNING: multiple messages have this Message-ID (diff)
From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.garry@huawei.com>,
martin.petersen@oracle.com, jejb@linux.vnet.ibm.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
zhaohongjiang@huawei.com, hare@suse.com,
dan.j.williams@intel.com, jthumshirn@suse.de, hch@lst.de,
huangdaode@hisilicon.com, chenxiang66@hisilicon.com,
xiexiuqi@huawei.com, tj@kernel.org, miaoxie@huawei.com,
Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH 4/8] scsi: libsas: trigger a new revalidation to discover the device
Date: Mon, 4 Jun 2018 09:01:38 +0800 [thread overview]
Message-ID: <5B148F72.3000000@huawei.com> (raw)
In-Reply-To: <6b030b96-9733-f6b5-e8af-d1d488c52fb4@huawei.com>
On 2018/6/1 18:02, John Garry wrote:
> I mean that since libsas does disocovery/revalidation for all expander
> PHYS for a single event, than all discovery/revalidation should be
> synchronised with that same event. I don't mean that for a given
> expander PHY which originated a broadcast event, the
> revalidation/discovery for that PHY should be synchronised with that
> same event. Like you said, I don't think it's possible.
>
> On another point, one of the reasons to synchronise event processing was
> so events are not lost and are processed in order. In principle, by
> chaining these bcast events we lose that, since other PHY events may be
> queued before we queue the new artificial bcast events.
>
I got what you mean. I will try to keep the principle of synchronised
event processing.
>>
>> But if you mean we shall do this device removing and rediscovering in
>> one revalidation if it is not a "flutter", I think we can wrap a new
>> function for sas_revalidate_domain(), such as:
>>
>>
>> while (need_to_revalidate_again)
>> need_to_revalidate_again = sas_revalidate_domain()
>>
>> In this way the sas_port adding/removing is packed in one loop, we won't
>> have the annoyance of "duplicate filename" warning. What do you
>> think?
>
> Something like that, where all the discovery/revalidation and related
> device + port processing is done before we complete the revalidation
> event processing. A single revalidation event may defer do device+port
> processing multiple times.
next prev parent reply other threads:[~2018-06-04 1:02 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-29 2:23 [PATCH 0/8] libsas: Support swapping disks and SATA phy link rate matching the pathway Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 2:23 ` [PATCH 1/8] scsi: libsas: delete dead code in scsi_transport_sas.c Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 7:33 ` Johannes Thumshirn
2018-05-31 14:26 ` John Garry
2018-05-31 14:26 ` John Garry
2018-05-29 2:23 ` [PATCH 2/8] scsi: libsas: check the lldd callback correctly Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 7:34 ` Johannes Thumshirn
2018-05-31 14:09 ` John Garry
2018-05-31 14:09 ` John Garry
2018-06-01 0:15 ` Jason Yan
2018-06-01 0:15 ` Jason Yan
2018-05-29 2:23 ` [PATCH 3/8] scsi: libsas: always unregister the old device if going to discover new Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 7:37 ` Johannes Thumshirn
2018-05-31 15:09 ` John Garry
2018-05-31 15:09 ` John Garry
2018-06-01 0:28 ` Jason Yan
2018-06-01 0:28 ` Jason Yan
2018-05-29 2:23 ` [PATCH 4/8] scsi: libsas: trigger a new revalidation to discover the device Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 7:43 ` Johannes Thumshirn
2018-05-31 15:42 ` John Garry
2018-05-31 15:42 ` John Garry
2018-06-01 0:59 ` Jason Yan
2018-06-01 0:59 ` Jason Yan
2018-06-01 10:02 ` John Garry
2018-06-01 10:02 ` John Garry
2018-06-04 1:01 ` Jason Yan [this message]
2018-06-04 1:01 ` Jason Yan
2018-05-29 2:23 ` [PATCH 5/8] scsi: libsas: check if the same sata device when flutter Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 2:23 ` [PATCH 6/8] scsi: libsas: reset the phy state and address if discover failed Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 2:23 ` [PATCH 7/8] scsi: libsas: fix issue of swapping two sas disks Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-29 2:23 ` [PATCH 8/8] scsi: libsas: support SATA phy link rate unmatch the pathway Jason Yan
2018-05-29 2:23 ` Jason Yan
2018-05-31 16:05 ` John Garry
2018-05-31 16:05 ` John Garry
2018-06-01 1:21 ` Jason Yan
2018-06-01 1:21 ` Jason Yan
2018-06-01 10:13 ` John Garry
2018-06-01 10:13 ` John Garry
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=5B148F72.3000000@huawei.com \
--to=yanaijie@huawei.com \
--cc=chenxiang66@hisilicon.com \
--cc=dan.j.williams@intel.com \
--cc=emilne@redhat.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=huangdaode@hisilicon.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=john.garry@huawei.com \
--cc=jthumshirn@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=miaoxie@huawei.com \
--cc=thenzl@redhat.com \
--cc=tj@kernel.org \
--cc=xiexiuqi@huawei.com \
--cc=zhaohongjiang@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.