1. 07 1月, 2006 1 次提交
    • N
      [PATCH] md: remove personality numbering from md · 2604b703
      NeilBrown 提交于
      md supports multiple different RAID level, each being implemented by a
      'personality' (which is often in a separate module).
      
      These personalities have fairly artificial 'numbers'.  The numbers
      are use to:
       1- provide an index into an array where the various personalities
          are recorded
       2- identify the module (via an alias) which implements are particular
          personality.
      
      Neither of these uses really justify the existence of personality numbers.
      The array can be replaced by a linked list which is searched (array lookup
      only happens very rarely).  Module identification can be done using an alias
      based on level rather than 'personality' number.
      
      The current 'raid5' modules support two level (4 and 5) but only one
      personality.  This slight awkwardness (which was handled in the mapping from
      level to personality) can be better handled by allowing raid5 to register 2
      personalities.
      
      With this change in place, the core md module does not need to have an
      exhaustive list of all possible personalities, so other personalities can be
      added independently.
      
      This patch also moves the check for chunksize being non-zero into the ->run
      routines for the personalities that need it, rather than having it in core-md.
       This has a side effect of allowing 'faulty' and 'linear' not to have a
      chunk-size set.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2604b703
  2. 09 11月, 2005 2 次提交
    • N
      [PATCH] md: support BIO_RW_BARRIER for md/raid1 · a9701a30
      NeilBrown 提交于
      We can only accept BARRIER requests if all slaves handle
      barriers, and that can, of course, change with time....
      
      So we keep track of whether the whole array seems safe for barriers,
      and also whether each individual rdev handles barriers.
      
      We initially assumes barriers are OK.
      
      When writing the superblock we try a barrier, and if that fails, we flag
      things for no-barriers.  This will usually clear the flags fairly quickly.
      
      If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
      resubmit, so introduce function "md_super_wait" which waits for requests to
      finish, and retries ENOTSUPP requests without the barrier flag.
      
      When writing the real raid1, write requests which were BIO_RW_BARRIER but
      which aresn't supported need to be retried.  So raid1d is enhanced to do this,
      and when any bio write completes (i.e.  no retry needed) we remove it from the
      r1bio, so that devices needing retry are easy to find.
      
      We should hardly ever get -ENOTSUPP errors when writing data to the raid.
      It should only happen if:
        1/ the device used to support BARRIER, but now doesn't.  Few devices
           change like this, though raid1 can!
      or
        2/ the array has no persistent superblock, so there was no opportunity to
           pre-test for barriers when writing the superblock.
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a9701a30
    • N
      [PATCH] md: make md on-disk bitmaps not host-endian · bd926c63
      NeilBrown 提交于
      Current bitmaps use set_bit et.al and so are host-endian, which means
      not-portable.  Oops.
      
      Define a new version number (4) for which bitmaps are little-endian.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bd926c63
  3. 22 6月, 2005 3 次提交
  4. 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