On 12/10/2015 4:53 PM, Uma Krishnan wrote:
From: "Matthew R. Ochs" <mro...@linux.vnet.ibm.com>
Applications which use virtual LUN's that are backed by a physical LUN
over both adapter ports may experience an I/O failure in the event of
a link loss (e.g. cable pull).
Virtual LUNs may be accessed through one or both ports of the adapter.
This access is encoded in the translation entries that comprise the
virtual LUN and used by the AFU for load-balancing I/O and handling
failover scenarios. In a link loss scenario, even though the AFU is
able to maintain connectivity to the LUN, it is up to the application
to retry the failed I/O. When applications are unaware of the virtual
LUN's underlying topology, they are unable to make a sound decision of
when to retry an I/O and therefore are forced to make their reaction to
a failed I/O absolute. The result is either a failure to retry I/O or
increased latency for scenarios where a retry is pointless.
To remedy this scenario, provide feedback back to the application on
virtual LUN creation as to which ports the LUN may be accessed. LUN's
spanning both ports are candidates for a retry in a presence of an I/O
failure.
Signed-off-by: Matthew R. Ochs <mro...@linux.vnet.ibm.com>
---
Reviewed-by: Uma Krishnan <ukri...@linux.vnet.ibm.com>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
