On 01/02/2019 01:58, Jason Yan wrote:
On 2019/2/1 0:38, John Garry wrote:
On 31/01/2019 10:29, John Garry wrote:
On 31/01/2019 02:04, Jason Yan wrote:
On 2019/1/31 1:22, John Garry wrote:
On 30/01/2019 08:24, Jason Yan wrote:
Now if a new device replaced a old device, the sas address will
change.
Hmmm... not if it's a SATA disk, which would have some same invented
SAS
address.
Yes, it's only for a SAS disk.
We unregister the old device and discover the new device in one
revalidation process. But after we deferred the sas_port_delete(),
the
sas port is not deleted when we registering the new port and device.
The sas port cannot be added because the name of the new port is the
same as the old.
Fix this by doing the replacement in two steps. The first
revalidation
only delete the old device and trigger a new revalidation. The second
revalidation discover the new device. To keep the event processing
synchronised to the original event,
This change seems ok, but please see below regarding generating the
bcast events.
Did I originally suggest this? It seems to needlessly make the code
more
complicated.
Yes, my first version was raise a new bcast event, and you said it's
not
synchronised to the original event. Shall I get back to that approach?
Not sure. This patch seems to fix something closely related to that in
"scsi: libsas: fix issue of swapping two sas disks", which I will check
further.
An idea:
So, before the libsas changes to generate dynamic events, when libsas
was processing a particular event type - like a broadcast event - extra
events generated by the LLDD were discarded by libsas.
The revalidation process attempted to do all revalidation for the domain
is a single pass, which was ok. This really did not change.
However, in this revalidation pass, we also clear all expander and PHY
events.
Actually we only clean one expander and it's attached PHYs events now.
ok, fine, it's just for one expander; but we still do clear that one
expanders events fully.
However we would have to be careful here to ensure that we don't have a
situation where we still have PHY events pending but no broadcast events
to trigger the revalidation and subsequent processing.
Maybe this is not the right thing to do. Maybe we should just clear a
single PHY event per pass, since we're processing each broadcast event
one-by-one.
Yes, we can do this. But I don't understand how this will fix the issue?
It would solve the problem of having to fixup the expanders events = -1,
which I mentioned was not so nice.
As for fixing the main problem, I was not against the idea of the other
change in sas_rediscover_dev() to not call sas_discover_new() when the
SAS address has changed.
We have this issue now because we have to probe the sas port and/or
delete the sas port out side of the disco_mutex. So for a specific PHY,
we cannot add and delete at the same time inside the disco_mutex.
Today you will notice that if we remove a disk for example, many
broadcast events are generated, but only the first broadcast event
actually does any revalidation.
EOM
.
