• Mike Snitzer's avatar
    dm: disable DISCARD if the underlying storage no longer supports it · bcb44433
    Mike Snitzer authored
    Storage devices which report supporting discard commands like
    WRITE_SAME_16 with unmap, but reject discard commands sent to the
    storage device.  This is a clear storage firmware bug but it doesn't
    change the fact that should a program cause discards to be sent to a
    multipath device layered on this buggy storage, all paths can end up
    failed at the same time from the discards, causing possible I/O loss.
    
    The first discard to a path will fail with Illegal Request, Invalid
    field in cdb, e.g.:
     kernel: sd 8:0:8:19: [sdfn] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
     kernel: sd 8:0:8:19: [sdfn] tag#0 Sense Key : Illegal Request [current]
     kernel: sd 8:0:8:19: [sdfn] tag#0 Add. Sense: Invalid field in cdb
     kernel: sd 8:0:8:19: [sdfn] tag#0 CDB: Write same(16) 93 08 00 00 00 00 00 a0 08 00 00 00 80 00 00 00
     kernel: blk_update_request: critical target error, dev sdfn, sector 10487808
    
    The SCSI layer converts this to the BLK_STS_TARGET error number, the sd
    device disables its support for discard on this path, and because of the
    BLK_STS_TARGET error multipath fails the discard without failing any
    path or retrying down a different path.  But subsequent discards can
    cause path failures.  Any discards sent to the path which already failed
    a discard ends up failing with EIO from blk_cloned_rq_check_limits with
    an "over max size limit" error since the discard limit was set to 0 by
    the sd driver for the path.  As the error is EIO, this now fails the
    path and multipath tries to send the discard down the next path.  This
    cycle continues as discards are sent until all paths fail.
    
    Fix this by training DM core to disable DISCARD if the underlying
    storage already did so.
    
    Also, fix branching in dm_done() and clone_endio() to reflect the
    mutually exclussive nature of the IO operations in question.
    
    Cc: stable@vger.kernel.org
    Reported-by: default avatarDavid Jeffery <djeffery@redhat.com>
    Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
    bcb44433
dm.c 73.8 KB