1. 07 2月, 2008 1 次提交
    • N
      md: Update md bitmap during resync. · b47490c9
      NeilBrown 提交于
      Currently an md array with a write-intent bitmap does not updated that bitmap
      to reflect successful partial resync.  Rather the entire bitmap is updated
      when the resync completes.
      
      This is because there is no guarentee that resync requests will complete in
      order, and tracking each request individually is unnecessarily burdensome.
      
      However there is value in regularly updating the bitmap, so add code to
      periodically pause while all pending sync requests complete, then update the
      bitmap.  Doing this only every few seconds (the same as the bitmap update
      time) does not notciably affect resync performance.
      
      [snitzer@gmail.com: export bitmap_cond_end_sync]
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Cc: "Mike Snitzer" <snitzer@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b47490c9
  2. 09 11月, 2007 1 次提交
  3. 23 10月, 2007 1 次提交
  4. 18 7月, 2007 2 次提交
  5. 24 5月, 2007 1 次提交
  6. 09 5月, 2007 1 次提交
  7. 13 4月, 2007 1 次提交
  8. 12 2月, 2007 1 次提交
  9. 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
  10. 27 1月, 2007 1 次提交
  11. 09 12月, 2006 1 次提交
  12. 22 10月, 2006 1 次提交
  13. 12 10月, 2006 1 次提交
  14. 03 10月, 2006 2 次提交
  15. 01 7月, 2006 1 次提交
  16. 27 6月, 2006 8 次提交
  17. 27 3月, 2006 1 次提交
  18. 26 3月, 2006 1 次提交
  19. 25 3月, 2006 1 次提交
  20. 15 1月, 2006 1 次提交
  21. 07 1月, 2006 7 次提交
  22. 18 11月, 2005 1 次提交
  23. 09 11月, 2005 3 次提交