1. 14 12月, 2009 2 次提交
    • N
      md: Support write-intent bitmaps with externally managed metadata. · ece5cff0
      NeilBrown 提交于
      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: NNeilBrown <neilb@suse.de>
      ece5cff0
    • N
      md: support updating bitmap parameters via sysfs. · 43a70507
      NeilBrown 提交于
      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: NNeilBrown <neilb@suse.de>
      Reviewed-by: NAndre Noll <maan@systemlinux.org>
      43a70507
  2. 31 3月, 2009 1 次提交
  3. 21 7月, 2008 1 次提交
    • N
      md: Tidy up rdev_size_store a bit: · d7027458
      Neil Brown 提交于
       - used strict_strtoull in place of simple_strtoull
       - use my_mddev in place of rdev->mddev (they have the same value)
      and more significantly,
       - don't adjust mddev->size to fit, rather reject changes which make
         rdev->size smaller than mddev->size
      
      Adjusting mddev->size is a hangover from bind_rdev_to_array which
      does a similar thing.  But it really is a better design to insist that
      mddev->size is set as required, then the rdev->sizes are set to allow
      for that.  The previous way invites confusion.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      d7027458
  4. 28 6月, 2008 4 次提交
  5. 28 4月, 2008 1 次提交
    • D
      md: introduce get_priority_stripe() to improve raid456 write performance · 8b3e6cdc
      Dan Williams 提交于
      Improve write performance by preventing the delayed_list from dumping all its
      stripes onto the handle_list in one shot.  Delayed stripes are now further
      delayed by being held on the 'hold_list'.  The 'hold_list' is bypassed when:
      
        * a STRIPE_IO_STARTED stripe is found at the head of 'handle_list'
        * 'handle_list' is empty and i/o is being done to satisfy full stripe-width
          write requests
        * 'bypass_count' is less than 'bypass_threshold'.  By default the threshold
          is 1, i.e. every other stripe handled is a preread stripe provided the
          top two conditions are false.
      
      Benchmark data:
      System: 2x Xeon 5150, 4x SATA, mem=1GB
      Baseline: 2.6.24-rc7
      Configuration: mdadm --create /dev/md0 /dev/sd[b-e] -n 4 -l 5 --assume-clean
      Test1: dd if=/dev/zero of=/dev/md0 bs=1024k count=2048
        * patched:  +33% (stripe_cache_size = 256), +25% (stripe_cache_size = 512)
      
      Test2: tiobench --size 2048 --numruns 5 --block 4096 --block 131072 (XFS)
        * patched: +13%
        * patched + preread_bypass_threshold = 0: +37%
      
      Changes since v1:
      * reduce bypass_threshold from (chunk_size / sectors_per_chunk) to (1) and
        make it configurable.  This defaults to fairness and modest performance
        gains out of the box.
      Changes since v2:
      * [neilb@suse.de]: kill STRIPE_PRIO_HI and preread_needed as they are not
        necessary, the important change was clearing STRIPE_DELAYED in
        add_stripe_bio and this has been moved out to make_request for the hang
        fix.
      * [neilb@suse.de]: simplify get_priority_stripe
      * [dan.j.williams@intel.com]: reset the bypass_count when ->hold_list is
        sampled empty (+11%)
      * [dan.j.williams@intel.com]: decrement the bypass_count at the detection
        of stripes being naturally promoted off of hold_list +2%.  Note, resetting
        bypass_count instead of decrementing on these events yields +4% but that is
        probably too aggressive.
      Changes since v3:
      * cosmetic fixups
      Tested-by: NJames W. Laferriere <babydr@baby-dragons.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8b3e6cdc
  6. 07 2月, 2008 1 次提交
  7. 10 5月, 2007 1 次提交
  8. 04 10月, 2006 4 次提交
  9. 03 10月, 2006 2 次提交
  10. 27 6月, 2006 6 次提交
  11. 07 1月, 2006 12 次提交
  12. 09 11月, 2005 1 次提交
  13. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4