Skip to content

L
linux
Switch branch/tag
  1. 26 Jul, 2011 5 commits
    • NeilBrown's avatar
      md/raid5: unify stripe_head_state and r6_state · f2b3b44d
      NeilBrown authored 
      'struct stripe_head_state' stores state about the 'current' stripe
that is passed around while handling the stripe.
For RAID6 there is an extension structure: r6_state, which is also
passed around.
There is no value in keeping these separate, so move the fields from
the latter into the former.

This means that all code now needs to treat s->failed_num as an small
array, but this is a small cost.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Reviewed-by: default avatarNamhyung Kim <namhyung@gmail.com>
      f2b3b44d
    • NeilBrown's avatar
      md/raid5: move common code into handle_stripe · 82e5a171
      NeilBrown authored 
      There is common code at the start of handle_stripe5 and
handle_stripe6.  Move it into handle_stripe.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Reviewed-by: default avatarNamhyung Kim <namhyung@gmail.com>
      82e5a171
    • NeilBrown's avatar
      md/raid5: replace sh->lock with an 'active' flag. · c4c1663b
      NeilBrown authored 
      sh->lock is now mainly used to ensure that two threads aren't running
in the locked part of handle_stripe[56] at the same time.

That can more neatly be achieved with an 'active' flag which we set
while running handle_stripe.  If we find the flag is set, we simply
requeue the stripe for later by setting STRIPE_HANDLE.

For safety we take ->device_lock while examining the state of the
stripe and creating a summary in 'stripe_head_state / r6_state'.
This possibly isn't needed but as shared fields like ->toread,
->towrite are checked it is safer for now at least.

We leave the label after the old 'unlock' called "unlock" because it
will disappear in a few patches, so renaming seems pointless.

This leaves the stripe 'locked' for longer as we clear STRIPE_ACTIVE
later, but that is not a problem.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Reviewed-by: default avatarNamhyung Kim <namhyung@gmail.com>
      c4c1663b
    • NeilBrown's avatar
      md/raid5: Protect some more code with ->device_lock. · cbe47ec5
      NeilBrown authored 
      Other places that change or follow dev->towrite and dev->written take
the device_lock as well as the sh->lock.
So it should really be held in these places too.
Also, doing so will allow sh->lock to be discarded.

with merged fixes by: Namhyung Kim <namhyung@gmail.com>
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Reviewed-by: default avatarNamhyung Kim <namhyung@gmail.com>
      cbe47ec5
    • NeilBrown's avatar
      md/raid5: Remove use of sh->lock in sync_request · 83206d66
      NeilBrown authored 
      This is the start of a series of patches to remove sh->lock.

sync_request takes sh->lock before setting STRIPE_SYNCING to ensure
there is no race with testing it in handle_stripe[56].

Instead, use a new flag STRIPE_SYNC_REQUESTED and test it early
in handle_stripe[56] (after getting the same lock) and perform the
same set/clear operations if it was set.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
Reviewed-by: default avatarNamhyung Kim <namhyung@gmail.com>
      83206d66
  3. 18 Jul, 2011 5 commits
  5. 16 Jul, 2011 2 commits
  7. 15 Jul, 2011 10 commits
  9. 14 Jul, 2011 2 commits
  11. 13 Jul, 2011 11 commits
  13. 12 Jul, 2011 5 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7