Re: Should multipath detect changed path UIDs?

[Tim Pepper <tpepper@gmail.com>]

Having the checker check for this change isn't a solution...it
shouldn't prevent any data corruption.  Even if you check prior to
every IO, you still have an obvious race between the check and the
subsequent IO.  You gain the ability to recognise the problem and
somehow magically warn the user (eg: disallow all subsequent IO to
catch the their attention).  So then what is a reasonable frequency
for the check?  How much corruption will you tolerate, because a lot
of IO can go out an FC connection in a short time.

Also, I'd think your #1 pre-requisite isn't quite right.  I'd say the
hole is wider and that you probably could have IO running heavily, as
long as none of it is failed by the lower layers in response to the
missing cable (and the default retries/timeouts could easily mask even
a clumsy cable swap).

Personally I'm also not inclined to think triggering hot plug events
on the cable removal/replacement is ideal.  I think fibre channel
isn't exactly intended as a dynamic environment and the SAN topology
is static or expected to be static from a given host's perspective. 
(I could be wrong.)  If this is the case, it would be helpful for a
host (or it's admin) to be able to know that topology and it's health
over time instead of only knowing the healthy portion of the topology
because the unhealthy parts are removed from its mappings.  Problem
determination seems like it's easier if you have a list of bad parts
instead of just a shrinking list of good parts.

Shouldn't the hba hardware/software be able to recognise and discern
between different classes of fabric failures, hba port link loss and
the return of a link that puts the port in a different place in the
SAN.  Does the HBA API give a common way to get detailed info out to
userspace daemons?