1. 28 3月, 2006 8 次提交
    • N
      [PATCH] md: Split reshape handler in check_reshape and start_reshape · 63c70c4f
      NeilBrown 提交于
      check_reshape checks validity and does things that can be done instantly -
      like adding devices to raid1.  start_reshape initiates a restriping process to
      convert the whole array.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      63c70c4f
    • N
      [PATCH] md: Only checkpoint expansion progress occasionally · b578d55f
      NeilBrown 提交于
      Instead of checkpointing at each stripe, only checkpoint when a new write
      would overwrite uncheckpointed data.  Block any write to the uncheckpointed
      area.  Arbitrarily checkpoint at least every 3Meg.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b578d55f
    • N
      [PATCH] md: Checkpoint and allow restart of raid5 reshape · f6705578
      NeilBrown 提交于
      We allow the superblock to record an 'old' and a 'new' geometry, and a
      position where any conversion is up to.  The geometry allows for changing
      chunksize, layout and level as well as number of devices.
      
      When using verion-0.90 superblock, we convert the version to 0.91 while the
      conversion is happening so that an old kernel will refuse the assemble the
      array.  For version-1, we use a feature bit for the same effect.
      
      When starting an array we check for an incomplete reshape and restart the
      reshape process if needed.  If the reshape stopped at an awkward time (like
      when updating the first stripe) we refuse to assemble the array, and let
      user-space worry about it.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f6705578
    • N
      [PATCH] md: Final stages of raid5 expand code · 29269553
      NeilBrown 提交于
      This patch adds raid5_reshape and end_reshape which will start and finish the
      reshape processes.
      
      raid5_reshape is only enabled in CONFIG_MD_RAID5_RESHAPE is set, to discourage
      accidental use.
      
      Read the 'help' for the CONFIG_MD_RAID5_RESHAPE entry.
      
      and Make sure that you have backups, just in case.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      29269553
    • N
      [PATCH] md: Core of raid5 resize process · ccfcc3c1
      NeilBrown 提交于
      This patch provides the core of the resize/expand process.
      
      sync_request notices if a 'reshape' is happening and acts accordingly.
      
      It allocated new stripe_heads for the next chunk-wide-stripe in the target
      geometry, marking them STRIPE_EXPANDING.
      
      Then it finds which stripe heads in the old geometry can provide data needed
      by these and marks them STRIPE_EXPAND_SOURCE.  This causes stripe_handle to
      read all blocks on those stripes.
      
      Once all blocks on a STRIPE_EXPAND_SOURCE stripe_head are read, any that are
      needed are copied into the corresponding STRIPE_EXPANDING stripe_head.  Once a
      STRIPE_EXPANDING stripe_head is full, it is marks STRIPE_EXPAND_READY and then
      is written out and released.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ccfcc3c1
    • N
      [PATCH] md: Infrastructure to allow normal IO to continue while array is expanding · 7ecaa1e6
      NeilBrown 提交于
      We need to allow that different stripes are of different effective sizes, and
      use the appropriate size.  Also, when a stripe is being expanded, we must
      block any IO attempts until the stripe is stable again.
      
      Key elements in this change are:
       - each stripe_head gets a 'disk' field which is part of the key,
         thus there can sometimes be two stripe heads of the same area of
         the array, but covering different numbers of devices.  One of these
         will be marked STRIPE_EXPANDING and so won't accept new requests.
       - conf->expand_progress tracks how the expansion is progressing and
         is used to determine whether the target part of the array has been
         expanded yet or not.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7ecaa1e6
    • N
      [PATCH] md: Allow stripes to be expanded in preparation for expanding an array · ad01c9e3
      NeilBrown 提交于
      Before a RAID-5 can be expanded, we need to be able to expand the stripe-cache
      data structure.
      
      This requires allocating new stripes in a new kmem_cache.  If this succeeds,
      we copy cache pages over and release the old stripes and kmem_cache.
      
      We then allocate new pages.  If that fails, we leave the stripe cache at it's
      new size.  It isn't worth the effort to shrink it back again.
      
      Unfortuanately this means we need two kmem_cache names as we, for a short
      period of time, we have two kmem_caches.  So they are raid5/%s and
      raid5/%s-alt
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ad01c9e3
    • N
      [PATCH] md: Split disks array out of raid5 conf structure so it is easier to grow · b55e6bfc
      NeilBrown 提交于
      The remainder of this batch implements raid5 reshaping.  Currently the only
      shape change that is supported is added a device, but it is envisioned that
      changing the chunksize and layout will also be supported, as well as changing
      the level (e.g.  1->5, 5->6).
      
      The reshape process naturally has to move all of the data in the array, and so
      should be used with caution.  It is believed to work, and some testing does
      support this, but wider testing would be great for increasing my confidence.
      
      You will need a version of mdadm newer than 2.3.1 to make use of raid5 growth.
       This is because mdadm need to take a copy of a 'critical section' at the
      start of the array incase there is a crash at an awkward moment.  On restart,
      mdadm will restore the critical section and allow reshape to continue.
      
      I hope to release a 2.4-pre by early next week - it still needs a little more
      polishing.
      
      This patch:
      
      Previously the array of disk information was included in the raid5 'conf'
      structure which was allocated to an appropriate size.  This makes it awkward
      to change the size of that array.  So we split it off into a separate
      kmalloced array which will require a little extra indexing, but is much easier
      to grow.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b55e6bfc
  2. 04 2月, 2006 1 次提交
  3. 15 1月, 2006 1 次提交
  4. 07 1月, 2006 10 次提交
  5. 13 12月, 2005 1 次提交
  6. 29 11月, 2005 1 次提交
  7. 09 11月, 2005 10 次提交
  8. 07 11月, 2005 1 次提交
  9. 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
  10. 10 9月, 2005 2 次提交
  11. 02 8月, 2005 1 次提交
  12. 28 7月, 2005 1 次提交
  13. 22 6月, 2005 2 次提交
    • N
      [PATCH] md: fix deadlock due to md thread processing delayed requests. · 3d310eb7
      NeilBrown 提交于
      Before completing a 'write' the md superblock might need to be updated.
      This is best done by the md_thread.
      
      The current code schedules this up and queues the write request for later
      handling by the md_thread.
      
      However some personalities (Raid5/raid6) will deadlock if the md_thread
      tries to submit requests to its own array.
      
      So this patch changes things so the processes submitting the request waits
      for the superblock to be written and then submits the request itself.
      
      This fixes a recently-created deadlock in raid5/raid6
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3d310eb7
    • N
      [PATCH] md: improve the interface to sync_request · 57afd89f
      NeilBrown 提交于
      1/ change the return value (which is number-of-sectors synced)
       from 'int' to 'sector_t'.
       The number of sectors is usually easily small enough to fit
       in an int, but if resync needs to abort, it may want to return
       the total number of remaining sectors, which could be large.
       Also errors cannot be returned as negative numbers now, so use
       0 instead
      2/ Add a 'skipped' return parameter to allow the array to report
       that it skipped the sectors.  This allows md to take this into account
       in the speed calculations.
       Currently there is no important skipping, but the bitmap-based-resync
       that is coming will use this.
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      57afd89f