1. 20 Apr, 2009 1 commit
  2. 17 Apr, 2009 1 commit
    • NeilBrown's avatar
      md: update sync_completed and reshape_position even more often. · c03f6a19
      NeilBrown authored
      There are circumstances when a user-space process might need to
      "oversee" a resync/reshape process.  For example when doing an
      in-place reshape of a raid5, it is prudent to take a backup of each
      section before reshaping it as this is the only way to provide
      safety against an unplanned shutdown (i.e. crash/power failure).
      
      The sync_max sysfs value can be used to stop the resync from
      advancing beyond a particular point.
      So user-space can:
        suspend IO to the first section and back it up
        set 'sync_max' to the end of the section
        wait for 'sync_completed' to reach that point
        resume IO on the first section and move on to the next section.
      
      However this process requires the kernel and user-space to run in
      lock-step which could introduce unnecessary delays.
      
      It would be better if a 'double buffered' approach could be used with
      userspace and kernel space working on different sections with the
      'next' section always ready when the 'current' section is finished.
      
      One problem with implementing this is that sync_completed is only
      guaranteed to be updated when the sync process reaches sync_max.
      (it is updated on a time basis at other times, but it is hard to rely
      on that).  This defeats some of the double buffering.
      
      With this patch, sync_completed (and reshape_position) get updated as
      the current position approaches sync_max, so there is room for
      userspace to advance sync_max early without losing updates.
      
      To be precise, sync_completed is updated when the current sync
      position reaches half way between the current value of sync_completed
      and the value of sync_max.  This will usually be a good time for user
      space to update sync_max.
      
      If sync_max does not get updated, the updates to sync_completed
      (together with associated metadata updates) will occur at an
      exponentially increasing frequency which will get unreasonably fast
      (one update every page) immediately before the process hits sync_max
      and stops.  So the update rate will be unreasonably fast only for an
      insignificant period of time.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c03f6a19
  3. 14 Apr, 2009 3 commits
    • NeilBrown's avatar
      md: improve usefulness and accuracy of sysfs file md/sync_completed. · acb180b0
      NeilBrown authored
      The sync_completed file reports how much of a resync (or recovery or
      reshape) has been completed.
      However due to the possibility of out-of-order completion of writes,
      it is not certain to be accurate.
      
      We have an internal value - mddev->curr_resync_completed - which is an
      accurate value (though it might not always be quite so uptodate).
      
      So:
       - make curr_resync_completed be uptodate a little more often,
         particularly when raid5 reshape updates status in the metadata
       - report curr_resync_completed in the sysfs file
       - allow poll/select to report all updates to md/sync_completed.
      
      This makes sync_completed completed usable by any external metadata
      handler that wants to record this status information in its metadata.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      acb180b0
    • NeilBrown's avatar
      md: allow setting newly added device to 'in_sync' via sysfs. · 6d56e278
      NeilBrown authored
      When adding devices to an active array via sysfs, there is currently
      no way to mark a device as 'in-sync' which is useful when
      incrementally assembling an array.
      
      So add that option.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      6d56e278
    • Christoph Hellwig's avatar
      md: tiny md.h cleanups · 63fe0817
      Christoph Hellwig authored
      - update inclusion guard and make sure it covers the whole file
       - remove superflous #ifdef CONFIG_BLOCK
       - make sure all required headers are included so that new users aren't
         required to include others before
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      63fe0817
  4. 11 Apr, 2009 2 commits
    • Linus Torvalds's avatar
      Revert "ACPI battery: fix async boot oops" · b0cbc861
      Linus Torvalds authored
      This reverts commit 5d38258e, since the
      underlying problem got fixed properly in the previous commit ("async:
      Fix module loading async-work regression").
      
      Cc: Arkadiusz Miskiewicz <a.miskiewicz@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      Cc: Len Brown <len.brown@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b0cbc861
    • Linus Torvalds's avatar
      async: Fix module loading async-work regression · d6de2c80
      Linus Torvalds authored
      Several drivers use asynchronous work to do device discovery, and we
      synchronize with them in the compiled-in case before we actually try to
      mount root filesystems etc.
      
      However, when compiled as modules, that synchronization is missing - the
      module loading completes, but the driver hasn't actually finished
      probing for devices, and that means that any user mode that expects to
      use the devices after the 'insmod' is now potentially broken.
      
      We already saw one case of a similar issue in the ACPI battery code,
      where the kernel itself expected the module to be all done, and unmapped
      the init memory - but the async device discovery was still running.
      That got hacked around by just removing the "__init" (see commit
      5d38258e "ACPI battery: fix async boot
      oops"), but the real fix is to just make the module loading wait for all
      async work to be completed.
      
      It will slow down module loading, but since common devices should be
      built in anyway, and since the bug is really annoying and hard to handle
      from user space (and caused several S3 resume regressions), the simple
      fix to wait is the right one.
      
      This fixes at least
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=13063
      
      but probably a few other bugzilla entries too (12936, for example), and
      is confirmed to fix Rafael's storage driver breakage after resume bug
      report (no bugzilla entry).
      
      We should also be able to now revert that ACPI battery fix.
      Reported-and-tested-by: default avatarRafael J. Wysocki <rjw@suse.com>
      Tested-by: default avatarHeinz Diehl <htd@fancy-poultry.org>
      Acked-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d6de2c80
  5. 10 Apr, 2009 8 commits
  6. 09 Apr, 2009 25 commits