1. 28 6月, 2008 1 次提交
    • N
      Improve setting of "events_cleared" for write-intent bitmaps. · a0da84f3
      Neil Brown 提交于
      When an array is degraded, bits in the write-intent bitmap are not
      cleared, so that if the missing device is re-added, it can be synced
      by only updated those parts of the device that have changed since
      it was removed.
      
      The enable this a 'events_cleared' value is stored. It is the event
      counter for the array the last time that any bits were cleared.
      
      Sometimes - if a device disappears from an array while it is 'clean' -
      the events_cleared value gets updated incorrectly (there are subtle
      ordering issues between updateing events in the main metadata and the
      bitmap metadata) resulting in the missing device appearing to require
      a full resync when it is re-added.
      
      With this patch, we update events_cleared precisely when we are about
      to clear a bit in the bitmap.  We record events_cleared when we clear
      the bit internally, and copy that to the superblock which is written
      out before the bit on storage.  This makes it more "obviously correct".
      
      We also need to update events_cleared when the event_count is going
      backwards (as happens on a dirty->clean transition of a non-degraded
      array).
      
      Thanks to Mike Snitzer for identifying this problem and testing early
      "fixes".
      
      Cc:  "Mike Snitzer" <snitzer@gmail.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      a0da84f3
  2. 25 5月, 2008 1 次提交
  3. 11 3月, 2008 1 次提交
  4. 05 3月, 2008 1 次提交
  5. 15 2月, 2008 1 次提交
  6. 07 2月, 2008 2 次提交
  7. 09 11月, 2007 1 次提交
  8. 23 10月, 2007 1 次提交
  9. 18 7月, 2007 2 次提交
  10. 24 5月, 2007 1 次提交
  11. 09 5月, 2007 1 次提交
  12. 13 4月, 2007 1 次提交
  13. 12 2月, 2007 1 次提交
  14. 10 2月, 2007 1 次提交
    • N
      [PATCH] md: avoid possible BUG_ON in md bitmap handling · da6e1a32
      Neil Brown 提交于
      md/bitmap tracks how many active write requests are pending on blocks
      associated with each bit in the bitmap, so that it knows when it can clear
      the bit (when count hits zero).
      
      The counter has 14 bits of space, so if there are ever more than 16383, we
      cannot cope.
      
      Currently the code just calles BUG_ON as "all" drivers have request queue
      limits much smaller than this.
      
      However is seems that some don't.  Apparently some multipath configurations
      can allow more than 16383 concurrent write requests.
      
      So, in this unlikely situation, instead of calling BUG_ON we now wait
      for the count to drop down a bit.  This requires a new wait_queue_head,
      some waiting code, and a wakeup call.
      
      Tested by limiting the counter to 20 instead of 16383 (writes go a lot slower
      in that case...).
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da6e1a32
  15. 27 1月, 2007 1 次提交
  16. 09 12月, 2006 1 次提交
  17. 22 10月, 2006 1 次提交
  18. 12 10月, 2006 1 次提交
  19. 03 10月, 2006 2 次提交
  20. 01 7月, 2006 1 次提交
  21. 27 6月, 2006 8 次提交
  22. 27 3月, 2006 1 次提交
  23. 26 3月, 2006 1 次提交
  24. 25 3月, 2006 1 次提交
  25. 15 1月, 2006 1 次提交
  26. 07 1月, 2006 5 次提交