1. 11 5月, 2011 1 次提交
    • N
      md/raid1: improve handling of pages allocated for write-behind. · af6d7b76
      NeilBrown 提交于
      The current handling and freeing of these pages is a bit fragile.
      We only keep the list of allocated pages in each bio, so we need to
      still have a valid bio when freeing the pages, which is a bit clumsy.
      
      So simply store the allocated page list in the r1_bio so it can easily
      be found and freed when we are finished with the r1_bio.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      af6d7b76
  2. 29 10月, 2010 1 次提交
  3. 10 9月, 2010 1 次提交
    • T
      md: implment REQ_FLUSH/FUA support · e9c7469b
      Tejun Heo 提交于
      This patch converts md to support REQ_FLUSH/FUA instead of now
      deprecated REQ_HARDBARRIER.  In the core part (md.c), the following
      changes are notable.
      
      * Unlike REQ_HARDBARRIER, REQ_FLUSH/FUA don't interfere with
        processing of other requests and thus there is no reason to mark the
        queue congested while FLUSH/FUA is in progress.
      
      * REQ_FLUSH/FUA failures are final and its users don't need retry
        logic.  Retry logic is removed.
      
      * Preflush needs to be issued to all member devices but FUA writes can
        be handled the same way as other writes - their processing can be
        deferred to request_queue of member devices.  md_barrier_request()
        is renamed to md_flush_request() and simplified accordingly.
      
      For linear, raid0 and multipath, the core changes are enough.  raid1,
      5 and 10 need the following conversions.
      
      * raid1: Handling of FLUSH/FUA bio's can simply be deferred to
        request_queues of member devices.  Barrier related logic removed.
      
      * raid5: Queue draining logic dropped.  FUA bit is propagated through
        biodrain and stripe resconstruction such that all the updated parts
        of the stripe are written out with FUA writes if any of the dirtying
        writes was FUA.  preread_active_stripes handling in make_request()
        is updated as suggested by Neil Brown.
      
      * raid10: FUA bit needs to be propagated to write clones.
      
      linear, raid0, 1, 5 and 10 tested.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reviewed-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NJens Axboe <jaxboe@fusionio.com>
      e9c7469b
  4. 14 12月, 2009 1 次提交
  5. 16 6月, 2009 1 次提交
    • N
      md: remove mddev_to_conf "helper" macro · 070ec55d
      NeilBrown 提交于
      Having a macro just to cast a void* isn't really helpful.
      I would must rather see that we are simply de-referencing ->private,
      than have to know what the macro does.
      
      So open code the macro everywhere and remove the pointless cast.
      Signed-off-by: NNeilBrown <neilb@suse.de>
      070ec55d
  6. 31 3月, 2009 2 次提交
  7. 03 10月, 2006 1 次提交
  8. 23 3月, 2006 1 次提交
  9. 07 1月, 2006 3 次提交
  10. 09 11月, 2005 1 次提交
    • 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
  11. 10 9月, 2005 1 次提交
  12. 22 6月, 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