• Matthew R. Ochs's avatar
    cxlflash: Fix to avoid virtual LUN failover failure · d5e26bb1
    Matthew R. Ochs authored
    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: default avatarMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
    Acked-by: default avatarManoj Kumar <manoj@linux.vnet.ibm.com>
    Reviewed-by: default avatarUma Krishnan <ukrishn@linux.vnet.ibm.com>
    Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
    d5e26bb1
vlun.c 35.1 KB