From: Namhyung Kim <namhyung@gmail.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: [md PATCH 19/34] md/raid5: move some more common code into handle_stripe
Date: Fri, 22 Jul 2011 18:29:16 +0900 [thread overview]
Message-ID: <87livqpssz.fsf@gmail.com> (raw)
In-Reply-To: <20110721023226.6728.58479.stgit@notabene.brown> (NeilBrown's message of "Thu, 21 Jul 2011 12:32:26 +1000")
NeilBrown <neilb@suse.de> writes:
> The RAID6 version of this code is usable for RAID5 providing:
> - we test "conf->max_degraded" rather than "2" as appropriate
> - we make sure s->failed_num[1] is meaningful (and not '-1')
> when s->failed > 1
>
> The 'return 1' must become 'goto finish' in the new location.
>
> Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Namhyung Kim <namhyung@gmail.com>
and nitpick below.
> ---
>
> drivers/md/raid5.c | 178 +++++++++++++++++++---------------------------------
> 1 files changed, 66 insertions(+), 112 deletions(-)
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index ba6f892..f23848f 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -2969,63 +2969,14 @@ static int handle_stripe5(struct stripe_head *sh, struct stripe_head_state *s)
> if (test_bit(R5_ReadError, &dev->flags))
> clear_bit(R5_Insync, &dev->flags);
> if (!test_bit(R5_Insync, &dev->flags)) {
> + if (s->failed < 2)
> + s->failed_num[s->failed] = i;
> s->failed++;
> - s->failed_num[0] = i;
> }
> }
> spin_unlock_irq(&conf->device_lock);
> rcu_read_unlock();
>
> - if (unlikely(s->blocked_rdev)) {
> - if (s->syncing || s->expanding || s->expanded ||
> - s->to_write || s->written) {
> - set_bit(STRIPE_HANDLE, &sh->state);
> - return 1;
> - }
> - /* There is nothing for the blocked_rdev to block */
> - rdev_dec_pending(s->blocked_rdev, conf->mddev);
> - s->blocked_rdev = NULL;
> - }
> -
> - if (s->to_fill && !test_bit(STRIPE_BIOFILL_RUN, &sh->state)) {
> - set_bit(STRIPE_OP_BIOFILL, &s->ops_request);
> - set_bit(STRIPE_BIOFILL_RUN, &sh->state);
> - }
> -
> - pr_debug("locked=%d uptodate=%d to_read=%d"
> - " to_write=%d failed=%d failed_num=%d\n",
> - s->locked, s->uptodate, s->to_read, s->to_write,
> - s->failed, s->failed_num[0]);
> - /* check if the array has lost two devices and, if so, some requests might
> - * need to be failed
> - */
> - if (s->failed > 1 && s->to_read+s->to_write+s->written)
> - handle_failed_stripe(conf, sh, s, disks, &s->return_bi);
> - if (s->failed > 1 && s->syncing) {
> - md_done_sync(conf->mddev, STRIPE_SECTORS,0);
> - clear_bit(STRIPE_SYNCING, &sh->state);
> - s->syncing = 0;
> - }
> -
> - /* might be able to return some write requests if the parity block
> - * is safe, or on a failed drive
> - */
> - dev = &sh->dev[sh->pd_idx];
> - if (s->written &&
> - ((test_bit(R5_Insync, &dev->flags) &&
> - !test_bit(R5_LOCKED, &dev->flags) &&
> - test_bit(R5_UPTODATE, &dev->flags)) ||
> - (s->failed == 1 && s->failed_num[0] == sh->pd_idx)))
> - handle_stripe_clean_event(conf, sh, disks, &s->return_bi);
> -
> - /* Now we might consider reading some blocks, either to check/generate
> - * parity, or to satisfy requests
> - * or to load a block that is being partially written.
> - */
> - if (s->to_read || s->non_overwrite ||
> - (s->syncing && (s->uptodate + s->compute < disks)) || s->expanding)
> - handle_stripe_fill(sh, s, disks);
> -
> return 0;
> }
>
> @@ -3033,8 +2984,8 @@ static int handle_stripe6(struct stripe_head *sh, struct stripe_head_state *s)
> {
> raid5_conf_t *conf = sh->raid_conf;
> int disks = sh->disks;
> - int i, pd_idx = sh->pd_idx, qd_idx = sh->qd_idx;
> - struct r5dev *dev, *pdev, *qdev;
> + struct r5dev *dev;
> + int i;
>
> /* Now to look around and see what can be done */
>
> @@ -3108,65 +3059,6 @@ static int handle_stripe6(struct stripe_head *sh, struct stripe_head_state *s)
> spin_unlock_irq(&conf->device_lock);
> rcu_read_unlock();
>
> - if (unlikely(s->blocked_rdev)) {
> - if (s->syncing || s->expanding || s->expanded ||
> - s->to_write || s->written) {
> - set_bit(STRIPE_HANDLE, &sh->state);
> - return 1;
> - }
> - /* There is nothing for the blocked_rdev to block */
> - rdev_dec_pending(s->blocked_rdev, conf->mddev);
> - s->blocked_rdev = NULL;
> - }
> -
> - if (s->to_fill && !test_bit(STRIPE_BIOFILL_RUN, &sh->state)) {
> - set_bit(STRIPE_OP_BIOFILL, &s->ops_request);
> - set_bit(STRIPE_BIOFILL_RUN, &sh->state);
> - }
> -
> - pr_debug("locked=%d uptodate=%d to_read=%d"
> - " to_write=%d failed=%d failed_num=%d,%d\n",
> - s->locked, s->uptodate, s->to_read, s->to_write, s->failed,
> - s->failed_num[0], s->failed_num[1]);
> - /* check if the array has lost >2 devices and, if so, some requests
> - * might need to be failed
> - */
> - if (s->failed > 2 && s->to_read+s->to_write+s->written)
> - handle_failed_stripe(conf, sh, s, disks, &s->return_bi);
> - if (s->failed > 2 && s->syncing) {
> - md_done_sync(conf->mddev, STRIPE_SECTORS,0);
> - clear_bit(STRIPE_SYNCING, &sh->state);
> - s->syncing = 0;
> - }
> -
> - /*
> - * might be able to return some write requests if the parity blocks
> - * are safe, or on a failed drive
> - */
> - pdev = &sh->dev[pd_idx];
> - s->p_failed = (s->failed >= 1 && s->failed_num[0] == pd_idx)
> - || (s->failed >= 2 && s->failed_num[1] == pd_idx);
> - qdev = &sh->dev[qd_idx];
> - s->q_failed = (s->failed >= 1 && s->failed_num[0] == qd_idx)
> - || (s->failed >= 2 && s->failed_num[1] == qd_idx);
> -
> - if (s->written &&
> - (s->p_failed || ((test_bit(R5_Insync, &pdev->flags)
> - && !test_bit(R5_LOCKED, &pdev->flags)
> - && test_bit(R5_UPTODATE, &pdev->flags)))) &&
> - (s->q_failed || ((test_bit(R5_Insync, &qdev->flags)
> - && !test_bit(R5_LOCKED, &qdev->flags)
> - && test_bit(R5_UPTODATE, &qdev->flags)))))
> - handle_stripe_clean_event(conf, sh, disks, &s->return_bi);
> -
> - /* Now we might consider reading some blocks, either to check/generate
> - * parity, or to satisfy requests
> - * or to load a block that is being partially written.
> - */
> - if (s->to_read || s->non_overwrite || (s->to_write && s->failed) ||
> - (s->syncing && (s->uptodate + s->compute < disks)) || s->expanding)
> - handle_stripe_fill(sh, s, disks);
> -
> return 0;
> }
>
> @@ -3178,6 +3070,7 @@ static void handle_stripe(struct stripe_head *sh)
> int i;
> int prexor;
> int disks = sh->disks;
> + struct r5dev *pdev, *qdev;
>
> clear_bit(STRIPE_HANDLE, &sh->state);
> if (test_and_set_bit(STRIPE_ACTIVE, &sh->state)) {
> @@ -3214,6 +3107,67 @@ static void handle_stripe(struct stripe_head *sh)
> if (done)
> goto finish;
>
> + if (unlikely(s.blocked_rdev)) {
> + if (s.syncing || s.expanding || s.expanded ||
> + s.to_write || s.written) {
> + set_bit(STRIPE_HANDLE, &sh->state);
> + goto finish;
> + }
> + /* There is nothing for the blocked_rdev to block */
> + rdev_dec_pending(s.blocked_rdev, conf->mddev);
> + s.blocked_rdev = NULL;
> + }
> +
> + if (s.to_fill && !test_bit(STRIPE_BIOFILL_RUN, &sh->state)) {
> + set_bit(STRIPE_OP_BIOFILL, &s.ops_request);
> + set_bit(STRIPE_BIOFILL_RUN, &sh->state);
> + }
> +
> + pr_debug("locked=%d uptodate=%d to_read=%d"
> + " to_write=%d failed=%d failed_num=%d,%d\n",
> + s.locked, s.uptodate, s.to_read, s.to_write, s.failed,
> + s.failed_num[0], s.failed_num[1]);
> + /* check if the array has lost >2 devices and, if so, some requests
> + * might need to be failed
/* check if the array has lost more than max_degraded devices and,
if so, some requests might need to be failed
Thanks.
> + */
> + if (s.failed > conf->max_degraded && s.to_read+s.to_write+s.written)
> + handle_failed_stripe(conf, sh, &s, disks, &s.return_bi);
> + if (s.failed > conf->max_degraded && s.syncing) {
> + md_done_sync(conf->mddev, STRIPE_SECTORS, 0);
> + clear_bit(STRIPE_SYNCING, &sh->state);
> + s.syncing = 0;
> + }
> +
> + /*
> + * might be able to return some write requests if the parity blocks
> + * are safe, or on a failed drive
> + */
> + pdev = &sh->dev[sh->pd_idx];
> + s.p_failed = (s.failed >= 1 && s.failed_num[0] == sh->pd_idx)
> + || (s.failed >= 2 && s.failed_num[1] == sh->pd_idx);
> + qdev = &sh->dev[sh->qd_idx];
> + s.q_failed = (s.failed >= 1 && s.failed_num[0] == sh->qd_idx)
> + || (s.failed >= 2 && s.failed_num[1] == sh->qd_idx)
> + || conf->level < 6;
> +
> + if (s.written &&
> + (s.p_failed || ((test_bit(R5_Insync, &pdev->flags)
> + && !test_bit(R5_LOCKED, &pdev->flags)
> + && test_bit(R5_UPTODATE, &pdev->flags)))) &&
> + (s.q_failed || ((test_bit(R5_Insync, &qdev->flags)
> + && !test_bit(R5_LOCKED, &qdev->flags)
> + && test_bit(R5_UPTODATE, &qdev->flags)))))
> + handle_stripe_clean_event(conf, sh, disks, &s.return_bi);
> +
> + /* Now we might consider reading some blocks, either to check/generate
> + * parity, or to satisfy requests
> + * or to load a block that is being partially written.
> + */
> + if (s.to_read || s.non_overwrite
> + || (conf->level == 6 && s.to_write && s.failed)
> + || (s.syncing && (s.uptodate + s.compute < disks)) || s.expanding)
> + handle_stripe_fill(sh, &s, disks);
> +
> /* Now we check to see if any write operations have recently
> * completed
> */
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-07-22 9:29 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-21 2:32 [md PATCH 00/34] md patches for 3.1 - part 1 NeilBrown
2011-07-21 2:32 ` [md PATCH 01/34] md/raid10: get rid of duplicated conditional expression NeilBrown
2011-07-21 2:32 ` [md PATCH 02/34] md/raid10: factor out common bio handling code NeilBrown
2011-07-21 2:32 ` [md PATCH 03/34] md/raid10: share pages between read and write bio's during recovery NeilBrown
2011-07-21 2:32 ` [md PATCH 05/34] md/raid5: get rid of duplicated call to bio_data_dir() NeilBrown
2011-07-21 2:32 ` [md PATCH 04/34] md/raid5: use kmem_cache_zalloc() NeilBrown
2011-07-21 2:32 ` [md PATCH 06/34] md/raid5: Remove use of sh->lock in sync_request NeilBrown
2011-07-22 3:39 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 11/34] md/raid5: add some more fields to stripe_head_state NeilBrown
2011-07-22 5:31 ` Namhyung Kim
2011-07-26 1:35 ` NeilBrown
2011-07-21 2:32 ` [md PATCH 07/34] md/raid5: Protect some more code with ->device_lock NeilBrown
2011-07-22 3:54 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 09/34] md/raid5: move common code into handle_stripe NeilBrown
2011-07-22 4:30 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 08/34] md/raid5: replace sh->lock with an 'active' flag NeilBrown
2011-07-22 4:27 ` Namhyung Kim
2011-07-22 4:49 ` NeilBrown
2011-07-22 5:03 ` Namhyung Kim
2011-08-03 22:47 ` Dan Williams
2011-08-03 23:35 ` NeilBrown
2011-08-03 23:45 ` Williams, Dan J
2011-08-04 0:18 ` NeilBrown
2011-07-21 2:32 ` [md PATCH 10/34] md/raid5: unify stripe_head_state and r6_state NeilBrown
2011-07-22 4:49 ` Namhyung Kim
2011-07-22 5:15 ` NeilBrown
2011-07-22 5:37 ` NeilBrown
2011-07-22 5:53 ` Namhyung Kim
2011-07-26 6:44 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 15/34] md/raid5: rearrange a test in fetch_block6 NeilBrown
2011-07-22 7:37 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 12/34] md/raid5: move stripe_head_state and more code into handle_stripe NeilBrown
2011-07-22 5:41 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 13/34] md/raid5: Move code for finishing a reconstruction " NeilBrown
2011-07-22 7:09 ` Namhyung Kim
2011-07-26 1:44 ` NeilBrown
2011-07-21 2:32 ` [md PATCH 19/34] md/raid5: move some more common code " NeilBrown
2011-07-22 9:29 ` Namhyung Kim [this message]
2011-07-26 1:59 ` NeilBrown
2011-07-21 2:32 ` [md PATCH 18/34] md/raid5: move " NeilBrown
2011-07-22 9:20 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 17/34] md/raid5: unite handle_stripe_dirtying5 and handle_stripe_dirtying6 NeilBrown
2011-07-22 9:10 ` Namhyung Kim
2011-07-26 1:52 ` NeilBrown
2011-07-26 2:41 ` H. Peter Anvin
2011-07-26 9:40 ` David Brown
2011-07-26 13:23 ` Namhyung Kim
2011-07-26 15:01 ` David Brown
2011-07-21 2:32 ` [md PATCH 14/34] md/raid5: move more code into common handle_stripe NeilBrown
2011-07-22 7:32 ` Namhyung Kim
2011-07-26 1:48 ` NeilBrown
2011-07-21 2:32 ` [md PATCH 16/34] md/raid5: unite fetch_block5 and fetch_block6 NeilBrown
2011-07-22 8:24 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 21/34] md: use proper little-endian bitops NeilBrown
2011-07-21 2:32 ` [md PATCH 23/34] md: introduce link/unlink_rdev() helpers NeilBrown
2011-07-21 2:32 ` [md PATCH 24/34] md: remove ro check in md_check_recovery() NeilBrown
2011-07-21 2:32 ` [md PATCH 20/34] md/raid5: finalise new merged handle_stripe NeilBrown
2011-07-22 9:36 ` Namhyung Kim
2011-07-26 2:02 ` NeilBrown
2011-07-26 4:50 ` Namhyung Kim
2011-07-21 2:32 ` [md PATCH 25/34] md: change managed of recovery_disabled NeilBrown
2011-07-21 2:32 ` [md PATCH 27/34] md/raid10: Improve decision on whether to fail a device with a read error NeilBrown
2011-07-21 2:32 ` [md PATCH 26/34] md/raid10: Make use of new recovery_disabled handling NeilBrown
2011-07-21 2:32 ` [md PATCH 22/34] md/raid: use printk_ratelimited instead of printk_ratelimit NeilBrown
2011-07-21 2:32 ` [md PATCH 30/34] md/raid5: move rdev->corrected_errors counting NeilBrown
2011-07-21 2:32 ` [md PATCH 33/34] MD: raid1 s/sysfs_notify_dirent/sysfs_notify_dirent_safe NeilBrown
2011-07-21 2:32 ` [md PATCH 29/34] md/raid1: move rdev->corrected_errors counting NeilBrown
2011-07-21 2:32 ` [md PATCH 34/34] MD bitmap: Revert DM dirty log hooks NeilBrown
2011-07-21 2:32 ` [md PATCH 28/34] md: get rid of unnecessary casts on page_address() NeilBrown
2011-07-21 2:32 ` [md PATCH 31/34] md/raid10: move rdev->corrected_errors counting NeilBrown
2011-07-21 2:32 ` [md PATCH 32/34] md/raid5: Avoid BUG caused by multiple failures NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87livqpssz.fsf@gmail.com \
--to=namhyung@gmail.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.