1. 24 Mar, 2011 8 commits
    • Mustafa Mesanovic's avatar
      dm stripe: implement merge method · 29915202
      Mustafa Mesanovic authored
      Implement a merge function in the striped target.
      
      When the striped target's underlying devices provide a merge_bvec_fn
      (like all DM devices do via dm_merge_bvec) it is important to call down
      to them when building a biovec that doesn't span a stripe boundary.
      
      Without the merge method, a striped DM device stacked on DM devices
      causes bios with a single page to be submitted which results
      in unnecessary overhead that hurts performance.
      
      This change really helps filesystems (e.g. XFS and now ext4) which take
      care to assemble larger bios.  By implementing stripe_merge(), DM and the
      stripe target no longer undermine the filesystem's work by only allowing
      a single page per bio.  Buffered IO sees the biggest improvement
      (particularly uncached reads, buffered writes to a lesser degree).  This
      is especially so for more capable "enterprise" storage LUNs.
      
      The performance improvement has been measured to be ~12-35% -- when a
      reasonable chunk_size is used (e.g. 64K) in conjunction with a stripe
      count that is a power of 2.
      
      In contrast, the performance penalty is ~5-7% for the pathological worst
      case stripe configuration (small chunk_size with a stripe count that is
      not a power of 2).  The reason for this is that stripe_map_sector() is
      now called once for every call to dm_merge_bvec().  stripe_map_sector()
      will use slower division if stripe count isn't a power of 2.
      Signed-off-by: default avatarMustafa Mesanovic <mume@linux.vnet.ibm.com>
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      29915202
    • Mike Snitzer's avatar
      dm mpath: allow table load with no priority groups · a490a07a
      Mike Snitzer authored
      This patch adjusts the multipath target to allow a table with both 0
      priority groups and 0 for the initial priority group number.
      
      If any mpath device is held open when all paths in the last priority
      group have failed, userspace multipathd will attempt to reload the
      associated DM table to reflect the fact that the device no longer has
      any priority groups.  But the reload attempt always failed because the
      multipath target did not allow 0 priority groups.
      
      All multipath target messages related to priority group (enable_group,
      disable_group, switch_group) will handle a priority group of 0 (will
      cause error).
      
      When reloading a multipath table with 0 priority groups, userspace
      multipathd must be updated to specify an initial priority group number
      of 0 (rather than 1).
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Cc: Babu Moger <babu.moger@lsi.com>
      Acked-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      a490a07a
    • Mike Snitzer's avatar
      dm mpath: fail message ioctl if specified path is not valid · 19040c0b
      Mike Snitzer authored
      Fail the reinstate_path and fail_path message ioctl if the specified
      path is not valid.
      
      The message ioctl would succeed for the 'reinistate_path' and
      'fail_path' messages even if action was not taken because the
      specified device was not a valid path of the multipath device.
      
      Before, when /dev/vdb is not a path of mpathb:
      $ dmsetup message mpathb 0 reinstate_path /dev/vdb
      $ echo $?
      0
      
      After:
      $ dmsetup message mpathb 0 reinstate_path /dev/vdb
      device-mapper: message ioctl failed: Invalid argument
      Command failed
      $ echo $?
      1
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      19040c0b
    • Milan Broz's avatar
      dm ioctl: add flag to wipe buffers for secure data · f8681205
      Milan Broz authored
      Add DM_SECURE_DATA_FLAG which userspace can use to ensure
      that all buffers allocated for dm-ioctl are wiped
      immediately after use.
      
      The user buffer is wiped as well (we do not want to keep
      and return sensitive data back to userspace if the flag is set).
      
      Wiping is useful for cryptsetup to ensure that the key
      is present in memory only in defined places and only
      for the time needed.
      
      (For crypt, key can be present in table during load or table
      status, wait and message commands).
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      f8681205
    • Milan Broz's avatar
      dm ioctl: prepare for crypt key wiping · 6bb43b5d
      Milan Broz authored
      Prepare code for implementing buffer wipe flag.
      No functional change in this patch.
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Acked-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      6bb43b5d
    • Milan Broz's avatar
      dm crypt: wipe keys string immediately after key is set · de8be5ac
      Milan Broz authored
      Always wipe the original copy of the key after processing it
      in crypt_set_key().
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Acked-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      de8be5ac
    • Josef Bacik's avatar
      dm: add flakey target · 3407ef52
      Josef Bacik authored
      This target is the same as the linear target except that it returns I/O
      errors periodically.  It's been found useful in simulating failing
      devices for testing purposes.
      
      I needed a dm target to do some failure testing on btrfs's raid code, and
      Mike pointed me at this.
      Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      3407ef52
    • Milan Broz's avatar
      dm: fix opening log and cow devices for read only tables · 024d37e9
      Milan Broz authored
      If a table is read-only, also open any log and cow devices it uses read-only.
      
      Previously, even read-only devices were opened read-write internally.
      After patch 75f1dc0d
        block: check bdev_read_only() from blkdev_get()
      was applied, loading such tables began to fail.  The patch
      was reverted by e51900f7
        block: revert block_dev read-only check
      but this patch fixes this part of the code to work with the original patch.
      Signed-off-by: default avatarMilan Broz <mbroz@redhat.com>
      Signed-off-by: default avatarAlasdair G Kergon <agk@redhat.com>
      024d37e9
  2. 23 Mar, 2011 32 commits