1. 14 Jun, 2016 17 commits
  2. 13 Jun, 2016 6 commits
  3. 07 Jun, 2016 1 commit
  4. 13 May, 2016 1 commit
  5. 02 Oct, 2015 1 commit
    • Mikulas Patocka's avatar
      dm raid: fix round up of default region size · 042745ee
      Mikulas Patocka authored
      Commit 3a0f9aae
      
       ("dm raid: round region_size to power of two")
      intended to make sure that the default region size is a power of two.
      However, the logic in that commit is incorrect and sets the variable
      region_size to 0 or 1, depending on whether min_region_size is a power
      of two.
      
      Fix this logic, using roundup_pow_of_two(), so that region_size is
      properly rounded up to the next power of two.
      
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Fixes: 3a0f9aae
      
       ("dm raid: round region_size to power of two")
      Cc: stable@vger.kernel.org # v3.8+
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      042745ee
  6. 13 Aug, 2015 1 commit
    • Kent Overstreet's avatar
      block: kill merge_bvec_fn() completely · 8ae12666
      Kent Overstreet authored
      
      
      As generic_make_request() is now able to handle arbitrarily sized bios,
      it's no longer necessary for each individual block driver to define its
      own ->merge_bvec_fn() callback. Remove every invocation completely.
      
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Lars Ellenberg <drbd-dev@lists.linbit.com>
      Cc: drbd-user@lists.linbit.com
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Yehuda Sadeh <yehuda@inktank.com>
      Cc: Sage Weil <sage@inktank.com>
      Cc: Alex Elder <elder@kernel.org>
      Cc: ceph-devel@vger.kernel.org
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Mike Snitzer <snitzer@redhat.com>
      Cc: dm-devel@redhat.com
      Cc: Neil Brown <neilb@suse.de>
      Cc: linux-raid@vger.kernel.org
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Acked-by: NeilBrown <neilb@suse.de> (for the 'md' bits)
      Acked-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarKent Overstreet <kent.overstreet@gmail.com>
      [dpark: also remove ->merge_bvec_fn() in dm-thin as well as
       dm-era-target, and resolve merge conflicts]
      Signed-off-by: default avatarDongsu Park <dpark@posteo.net>
      Signed-off-by: default avatarMing Lin <ming.l@ssi.samsung.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      8ae12666
  7. 29 May, 2015 3 commits
  8. 09 Feb, 2015 1 commit
  9. 03 Feb, 2015 1 commit
    • NeilBrown's avatar
      md: make ->congested robust against personality changes. · 5c675f83
      NeilBrown authored
      
      
      There is currently no locking around calls to the 'congested'
      bdi function.  If called at an awkward time while an array is
      being converted from one level (or personality) to another, there
      is a tiny chance of running code in an unreferenced module etc.
      
      So add a 'congested' function to the md_personality operations
      structure, and call it with appropriate locking from a central
      'mddev_congested'.
      
      When the array personality is changing the array will be 'suspended'
      so no IO is processed.
      If mddev_congested detects this, it simply reports that the
      array is congested, which is a safe guess.
      As mddev_suspend calls synchronize_rcu(), mddev_congested can
      avoid races by included the whole call inside an rcu_read_lock()
      region.
      This require that the congested functions for all subordinate devices
      can be run under rcu_lock.  Fortunately this is the case.
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      5c675f83
  10. 29 Oct, 2014 1 commit
  11. 21 Oct, 2014 1 commit
  12. 06 Oct, 2014 2 commits
  13. 26 Jun, 2013 1 commit
    • Jonathan Brassow's avatar
      MD: Remember the last sync operation that was performed · c4a39551
      Jonathan Brassow authored
      
      
      MD:  Remember the last sync operation that was performed
      
      This patch adds a field to the mddev structure to track the last
      sync operation that was performed.  This is especially useful when
      it comes to what is recorded in mismatch_cnt in sysfs.  If the
      last operation was "data-check", then it reports the number of
      descrepancies found by the user-initiated check.  If it was a
      "repair" operation, then it is reporting the number of
      descrepancies repaired.  etc.
      
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c4a39551
  14. 13 Jun, 2013 3 commits
    • Jingoo Han's avatar
      md: replace strict_strto*() with kstrto*() · b29bebd6
      Jingoo Han authored
      
      
      The usage of strict_strtoul() is not preferred, because
      strict_strtoul() is obsolete. Thus, kstrtoul() should be
      used.
      
      Signed-off-by: default avatarJingoo Han <jg1.han@samsung.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      b29bebd6
    • NeilBrown's avatar
      dm-raid: silence compiler warning on rebuilds_per_group. · 3f6bbd3f
      NeilBrown authored
      
      
      This doesn't really need to be initialised, but it doesn't hurt,
      silences the compiler, and as it is a counter it makes sense for it to
      start at zero.
      
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      3f6bbd3f
    • Jonathan Brassow's avatar
      DM RAID: Fix raid_resume not reviving failed devices in all cases · a4dc163a
      Jonathan Brassow authored
      
      
      DM RAID:  Fix raid_resume not reviving failed devices in all cases
      
      When a device fails in a RAID array, it is marked as Faulty.  Later,
      md_check_recovery is called which (through the call chain) calls
      'hot_remove_disk' in order to have the personalities remove the device
      from use in the array.
      
      Sometimes, it is possible for the array to be suspended before the
      personalities get their chance to perform 'hot_remove_disk'.  This is
      normally not an issue.  If the array is deactivated, then the failed
      device will be noticed when the array is reinstantiated.  If the
      array is resumed and the disk is still missing, md_check_recovery will
      be called upon resume and 'hot_remove_disk' will be called at that
      time.  However, (for dm-raid) if the device has been restored,
      a resume on the array would cause it to attempt to revive the device
      by calling 'hot_add_disk'.  If 'hot_remove_disk' had not been called,
      a situation is then created where the device is thought to concurrently
      be the replacement and the device to be replaced.  Thus, the device
      is first sync'ed with the rest of the array (because it is the replacement
      device) and then marked Faulty and removed from the array (because
      it is also the device being replaced).
      
      The solution is to check and see if the device had properly been removed
      before the array was suspended.  This is done by seeing whether the
      device's 'raid_disk' field is -1 - a condition that implies that
      'md_check_recovery -> remove_and_add_spares (where raid_disk is set to -1)
      -> hot_remove_disk' has been called.  If 'raid_disk' is not -1, then
      'hot_remove_disk' must be called to complete the removal of the previously
      faulty device before it can be revived via 'hot_add_disk'.
      
      Signed-off-by: default avatarJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      a4dc163a