1. 07 1月, 2006 7 次提交
  2. 29 11月, 2005 1 次提交
    • N
      [PATCH] md: improve read speed to raid10 arrays using 'far copies' · 22dfdf52
      NeilBrown 提交于
      raid10 has two different layouts.  One uses near-copies (so multiple
      copies of a block are at the same or similar offsets of different
      devices) and the other uses far-copies (so multiple copies of a block
      are stored a greatly different offsets on different devices).  The point
      of far-copies is that it allows the first section (normally first half)
      to be layed out in normal raid0 style, and thus provide raid0 sequential
      read performance.
      
      Unfortunately, the read balancing in raid10 makes some poor decisions
      for far-copies arrays and you don't get the desired performance.  So
      turn off that bad bit of read_balance for far-copies arrays.
      
      With this patch, read speed of an 'f2' array is comparable with a raid0
      with the same number of devices, though write speed is ofcourse still
      very slow.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22dfdf52
  3. 09 11月, 2005 2 次提交
  4. 01 11月, 2005 1 次提交
    • J
      [BLOCK] Unify the seperate read/write io stat fields into arrays · a362357b
      Jens Axboe 提交于
      Instead of having ->read_sectors and ->write_sectors, combine the two
      into ->sectors[2] and similar for the other fields. This saves a branch
      several places in the io path, since we don't have to care for what the
      actual io direction is. On my x86-64 box, that's 200 bytes less text in
      just the core (not counting the various drivers).
      Signed-off-by: NJens Axboe <axboe@suse.de>
      a362357b
  5. 09 10月, 2005 1 次提交
  6. 10 9月, 2005 4 次提交
  7. 22 6月, 2005 5 次提交
  8. 17 5月, 2005 1 次提交
  9. 01 5月, 2005 1 次提交
  10. 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