1. 05 May, 2010 2 commits
    • James Bottomley's avatar
      [SCSI] Retry commands with UNIT_ATTENTION sense codes to fix ext3/ext4 I/O error · 77a42297
      James Bottomley authored
      There's nastyness in the way we currently handle barriers (and
      discards): They're effectively filesystem commands, but they get
      processed as BLOCK_PC commands.  Unfortunately BLOCK_PC commands are
      taken by SCSI to be SG_IO commands and the issuer expects to see and
      handle any returned errors, however trivial.  This leads to a huge
      problem, because the block layer doesn't expect this to happen and any
      trivially retryable error on a barrier causes an immediate I/O error
      to the filesystem.
      
      The only real way to hack around this is to take the usual class of
      offending errors (unit attentions) and make them all retryable in the
      case of a REQ_HARDBARRIER.  A correct fix would involve a rework of
      the entire block and SCSI submit system, and so is out of scope for a
      quick fix.
      
      Cc: Hannes Reinecke <hare@suse.de>
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      77a42297
    • Hannes Reinecke's avatar
      [SCSI] Enable retries for SYNCRONIZE_CACHE commands to fix I/O error · c213e140
      Hannes Reinecke authored
      Some arrays are giving I/O errors with ext3 filesystems when
      SYNCHRONIZE_CACHE gets a UNIT_ATTENTION.  What is happening is that
      these commands have no retries, so the UNIT_ATTENTION causes the
      barrier to fail.  We should be enable retries here to clear any
      transient error and allow the barrier to succeed.
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Cc: Stable Tree <stable@kernel.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@suse.de>
      c213e140
  2. 02 May, 2010 2 commits
  3. 01 May, 2010 2 commits
  4. 30 Apr, 2010 34 commits