1. 14 Dec, 2009 21 commits
    • Robert Becker's avatar
      raid: improve MD/raid10 handling of correctable read errors. · 1e50915f
      Robert Becker authored
      We've noticed severe lasting performance degradation of our raid
      arrays when we have drives that yield large amounts of media errors.
      The raid10 module will queue each failed read for retry, and also
      will attempt call fix_read_error() to perform the read recovery.
      Read recovery is performed while the array is frozen, so repeated
      recovery attempts can degrade the performance of the array for
      extended periods of time.
      
      With this patch I propose adding a per md device max number of
      corrected read attempts.  Each rdev will maintain a count of
      read correction attempts in the rdev->read_errors field (not
      used currently for raid10). When we enter fix_read_error()
      we'll check to see when the last read error occurred, and
      divide the read error count by 2 for every hour since the
      last read error. If at that point our read error count
      exceeds the read error threshold, we'll fail the raid device.
      
      In addition in this patch I add sysfs nodes (get/set) for
      the per md max_read_errors attribute, the rdev->read_errors
      attribute, and added some printk's to indicate when
      fix_read_error fails to repair an rdev.
      
      For testing I used debugfs->fail_make_request to inject
      IO errors to the rdev while doing IO to the raid array.
      Signed-off-by: default avatarRobert Becker <Rob.Becker@riverbed.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      1e50915f
    • Robert Becker's avatar
      md/raid10: print more useful messages on device failure. · 67b8dc4b
      Robert Becker authored
      When we get a read error on a device in a RAID10, and attempting to
      repair the error fails, print more useful messages about why it
      failed.
      Signed-off-by: default avatarRobert Becker <Rob.Becker@riverbed.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      67b8dc4b
    • NeilBrown's avatar
      md/bitmap: update dirty flag when bitmap bits are explicitly set. · ffa23322
      NeilBrown authored
      There is a sysfs file which allows bits in the write-intent
      bitmap to be explicit set - indicating that the block is thought
      to be 'dirty'.
      When this happens we should really set recovery_cp backwards
      to include the block to reflect this dirtiness.
      
      In particular, a 'resync' process will refuse to start if
      recovery_cp is beyond the end of the array, so this is needed
      to allow a resync to be triggered.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      ffa23322
    • NeilBrown's avatar
      md: Support write-intent bitmaps with externally managed metadata. · ece5cff0
      NeilBrown authored
      In this case, the metadata needs to not be in the same
      sector as the bitmap.
      md will not read/write any bitmap metadata.  Config must be
      done via sysfs and when a recovery makes the array non-degraded
      again, writing 'true' to 'bitmap/can_clear' will allow bits in
      the bitmap to be cleared again.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      ece5cff0
    • NeilBrown's avatar
      md/bitmap: move setting of daemon_lastrun out of bitmap_read_sb · 624ce4f5
      NeilBrown authored
      Setting daemon_lastrun really has nothing to do with reading
      the bitmap superblock, it just happens to be needed at the same time.
      bitmap_read_sb is about to become options, so move that code out
      to after the call to bitmap_read_sb.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      624ce4f5
    • NeilBrown's avatar
      md: support updating bitmap parameters via sysfs. · 43a70507
      NeilBrown authored
      A new attribute directory 'bitmap' in 'md' is created which
      contains files for configuring the bitmap.
      'location' identifies where the bitmap is, either 'none',
      or 'file' or 'sector offset from metadata'.
      Writing 'location' can create or remove a bitmap.
      Adding a 'file' bitmap this way is not yet supported.
      'chunksize' and 'time_base' must be set before 'location'
      can be set.
      
      'chunksize' can be set before creating a bitmap, but is
      currently always over-ridden by the bitmap superblock.
      
      'time_base' and 'backlog' can be updated at any time.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      43a70507
    • NeilBrown's avatar
      md: factor out parsing of fixed-point numbers · 72e02075
      NeilBrown authored
      safe_delay_store can parse fixed point numbers (for fractions
      of a second).  We will want to do that for another sysfs
      file soon, so factor out the code.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      72e02075
    • NeilBrown's avatar
      md: support bitmap offset appropriate for external-metadata arrays. · f6af949c
      NeilBrown authored
      For md arrays were metadata is managed externally, the kernel does not
      know about a superblock so the superblock offset is 0.
      If we want to have a write-intent-bitmap near the end of the
      devices of such an array, we should support sector_t sized offset.
      We need offset be possibly negative for when the bitmap is before
      the metadata, so use loff_t instead.
      
      Also add sanity check that bitmap does not overlap with data.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      f6af949c
    • NeilBrown's avatar
      md: remove needless setting of thread->timeout in raid10_quiesce · 9cd30fdc
      NeilBrown authored
      As bitmap_create and bitmap_destroy already set thread->timeout
      as appropriate, there is no need to do it in raid10_quiesce.
      There is a possible need to wake the thread after the timeout
      has been set low, but it is better to do that where the timeout
      is actually set low, in bitmap_create.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      9cd30fdc
    • NeilBrown's avatar
      md: change daemon_sleep to be in 'jiffies' rather than 'seconds'. · 1b04be96
      NeilBrown authored
      This removes a lot of multiplications by HZ.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      1b04be96
    • NeilBrown's avatar
      md: move offset, daemon_sleep and chunksize out of bitmap structure · 42a04b50
      NeilBrown authored
      ... and into bitmap_info.  These are all configuration parameters
      that need to be set before the bitmap is created.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      42a04b50
    • NeilBrown's avatar
      md: collect bitmap-specific fields into one structure. · c3d9714e
      NeilBrown authored
      In preparation for making bitmap fields configurable via sysfs,
      start tidying up by making a single structure to contain the
      configuration fields.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c3d9714e
    • NeilBrown's avatar
      md/raid1: add takeover support for raid5->raid1 · 709ae487
      NeilBrown authored
      A 2-device raid5 array can now be converted to raid1.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      709ae487
    • NeilBrown's avatar
      md: add honouring of suspend_{lo,hi} to raid1. · 6eef4b21
      NeilBrown authored
      This will allow us to stop writeout to portions of the array
      while  they are resynced by someone else - e.g. another node in
      a cluster.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      6eef4b21
    • NeilBrown's avatar
      md/raid5: don't complete make_request on barrier until writes are scheduled · 729a1866
      NeilBrown authored
      The post-barrier-flush is sent by md as soon as make_request on the
      barrier write completes.  For raid5, the data might not be in the
      per-device queues yet.  So for barrier requests, wait for any
      pre-reading to be done so that the request will be in the per-device
      queues.
      
      We use the 'preread_active' count to check that nothing is still in
      the preread phase, and delay the decrement of this count until after
      write requests have been submitted to the underlying devices.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      729a1866
    • NeilBrown's avatar
      md: support barrier requests on all personalities. · a2826aa9
      NeilBrown authored
      Previously barriers were only supported on RAID1.  This is because
      other levels requires synchronisation across all devices and so needed
      a different approach.
      Here is that approach.
      
      When a barrier arrives, we send a zero-length barrier to every active
      device.  When that completes - and if the original request was not
      empty -  we submit the barrier request itself (with the barrier flag
      cleared) and then submit a fresh load of zero length barriers.
      
      The barrier request itself is asynchronous, but any subsequent
      request will block until the barrier completes.
      
      The reason for clearing the barrier flag is that a barrier request is
      allowed to fail.  If we pass a non-empty barrier through a striping
      raid level it is conceivable that part of it could succeed and part
      could fail.  That would be way too hard to deal with.
      So if the first run of zero length barriers succeed, we assume all is
      sufficiently well that we send the request and ignore errors in the
      second run of barriers.
      
      RAID5 needs extra care as write requests may not have been submitted
      to the underlying devices yet.  So we flush the stripe cache before
      proceeding with the barrier.
      
      Note that the second set of zero-length barriers are submitted
      immediately after the original request is submitted.  Thus when
      a personality finds mddev->barrier to be set during make_request,
      it should not return from make_request until the corresponding
      per-device request(s) have been queued.
      
      That will be done in later patches.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      a2826aa9
    • NeilBrown's avatar
      md: don't reset curr_resync_completed after an interrupted resync · efa59339
      NeilBrown authored
      If a resync/recovery/check/repair is interrupted for some reason, it
      can be useful to know exactly where it got up to.
      So in that case, do not clear curr_resync_completed.
      Initialise it when starting a resync/recovery/... instead.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      efa59339
    • NeilBrown's avatar
      md: adjust resync_min usefully when resync aborts. · c07b70ad
      NeilBrown authored
      When a 'check' or 'repair' finished we should clear resync_min
      so that a future check/repair will cover the whole array (by default).
      However if it is interrupted, we should update resync_min to
      where we got up to, so that when the check/repair continues it
      just does the remainder of the array.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c07b70ad
    • NeilBrown's avatar
      7820f9e1
    • NeilBrown's avatar
      md/raid5: remove some sparse warnings. · 8553fe7e
      NeilBrown authored
      qd_idx is previously declared and given exactly the same value!
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      8553fe7e
    • NeilBrown's avatar
      md/bitmap: protect against bitmap removal while being updated. · aa5cbd10
      NeilBrown authored
      A write intent bitmap can be removed from an array while the
      array is active.
      When this happens, all IO is suspended and flushed before the
      bitmap is removed.
      However it is possible that bitmap_daemon_work is still running to
      clear old bits from the bitmap.  If it is, it can dereference the
      bitmap after it has been freed.
      
      So introduce a new mutex to protect bitmap_daemon_work and get it
      before destroying a bitmap.
      
      This is suitable for any current -stable kernel.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Cc: stable@kernel.org
      aa5cbd10
  2. 12 Dec, 2009 19 commits