linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Robin Dong <robin.k.dong@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] md: set write-intent bit first in sync-bitmap for rwm in non-insync region.
Date: Tue, 23 Jul 2013 15:36:21 +1000	[thread overview]
Message-ID: <20130723153621.3f7e0eac@notabene.brown> (raw)
In-Reply-To: <1374473271-18551-2-git-send-email-robin.k.dong@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 6693 bytes --]

On Mon, 22 Jul 2013 14:07:51 +0800 Robin Dong <robin.k.dong@gmail.com> wrote:

> From: Robin Dong <sanbai@taobao.com>
> 
> If part of the RAID456 array is not in sync, then a read-modify-write cycle will
> update incorrect parity to new incorrect parity.  If you subsequently get a
> drive failure, any data on that drive in the not-in-sync region will be lost.
> 
> To avoid this, we:
>  1. In first bitmap_endwrite to a not-in-sync region, set the write-intent bit and
>     wake up resync thread.
>  2. When resync finishes, set the sync bit and clear write-intent bit.
> 
> Signed-off-by: Robin Dong <sanbai@taobao.com>
> Cc: NeilBrown <neilb@suse.de>
> ---
>  drivers/md/bitmap.c |   51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>  drivers/md/bitmap.h |    2 ++
>  drivers/md/raid5.c  |   11 +++++++++++
>  3 files changed, 63 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/md/bitmap.c b/drivers/md/bitmap.c
> index 0d894af..b4967c4 100644
> --- a/drivers/md/bitmap.c
> +++ b/drivers/md/bitmap.c
> @@ -1447,6 +1447,24 @@ int bitmap_startwrite(struct bitmap *bitmap, sector_t offset, unsigned long sect
>  }
>  EXPORT_SYMBOL(bitmap_startwrite);
>  
> +void syncbitmap_endwrite(struct bitmap *bitmap, sector_t offset,
> +		bitmap_counter_t *bmc)
> +{
> +	struct mddev *mddev = bitmap->mddev;
> +
> +	if (mddev->level >= 4 &&
> +	    offset > mddev->curr_resync_completed) {
> +		*bmc |= NEEDED_MASK;
> +		if (!test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) {
> +			set_bit(MD_RECOVERY_NEEDED, &mddev->recovery);
> +			set_bit(MD_RECOVERY_SYNC, &mddev->recovery);
> +			md_wakeup_thread(mddev->sync_thread);
> +			sysfs_notify_dirent_safe(mddev->sysfs_action);
> +		}
> +	} else
> +		syncbitmap_file_set_bit(bitmap, offset);
> +}
> +

I don't like the test for "level >= 4" here.
This would cause RAID10 to be treated differently to RAID1 and that isn't
right.

Can we just have the raid personality pass a flag (or maybe set a flag in
bitmap_info) to say if it wants auto-resync or not?


>  void bitmap_endwrite(struct bitmap *bitmap, sector_t offset, unsigned long sectors,
>  		     int success, int behind)
>  {
> @@ -1479,7 +1497,8 @@ void bitmap_endwrite(struct bitmap *bitmap, sector_t offset, unsigned long secto
>  			sysfs_notify_dirent_safe(bitmap->sysfs_can_clear);
>  		}
>  
> -		syncbitmap_file_set_bit(bitmap, offset);
> +		if (bitmap->mddev->bitmap_info.sync_bitmap)
> +			syncbitmap_endwrite(bitmap, offset, bmc);
>  
>  		if (!success && !NEEDED(*bmc))
>  			*bmc |= NEEDED_MASK;
> @@ -1502,6 +1521,36 @@ void bitmap_endwrite(struct bitmap *bitmap, sector_t offset, unsigned long secto
>  }
>  EXPORT_SYMBOL(bitmap_endwrite);
>  
> +void bitmap_in_synced(struct bitmap *bitmap, sector_t offset,
> +				unsigned long sectors)
> +{
> +	while (sectors) {
> +		sector_t blocks;
> +		unsigned long flags;
> +		bitmap_counter_t *bmc;
> +
> +		spin_lock_irqsave(&bitmap->counts.lock, flags);
> +		bmc = bitmap_get_counter(&bitmap->counts, offset, &blocks, 0);
> +		if (!bmc) {
> +			spin_unlock_irqrestore(&bitmap->counts.lock, flags);
> +			return;
> +		}
> +
> +		if (NEEDED(*bmc) || (!NEEDED(*bmc) && RESYNC(*bmc))) {
> +			*bmc &= ~NEEDED_MASK;
> +			syncbitmap_file_set_bit(bitmap, offset);
> +		}
> +
> +		spin_unlock_irqrestore(&bitmap->counts.lock, flags);
> +		offset += blocks;
> +		if (sectors > blocks)
> +			sectors -= blocks;
> +		else
> +			sectors = 0;
> +	}
> +}
> +EXPORT_SYMBOL(bitmap_in_synced);

This function is confusing me.  (maybe a comment at the top to explain it
would help???)

I think to get clarity we need a clear statement of which bitmap has priority.

I would expect:

 write-intent   sync bitmap     meaning
    0               0           chunk is unused.  No data here.
    0               1           chunk is clean and in sync. data is safe.
    1               0           Data might be here, full sync is needed.
    1               1           Data is here, full sync is needed.

So the syncbitmap bit can safely be set when the write-intent bit is set, but
must be set before it is cleared.

So I would always set the syncbitmap bit when setting the write-intent bit
(so the "1  0" row never exists).  For RAID5 if the syncbitmap bit wasn't set,
set set the NEEDED_MASK at the same time and trigger a resync.  Then the 
write-intent bit will not get cleared until the resync has happened.
So this special clearing of the NEEDED_MASK should not be needed.

Does that make sense?


Thanks,
NeilBrown



> +
>  static int __bitmap_start_sync(struct bitmap *bitmap, sector_t offset, sector_t *blocks,
>  			       int degraded)
>  {
> diff --git a/drivers/md/bitmap.h b/drivers/md/bitmap.h
> index ddc30da..6d22d8b 100644
> --- a/drivers/md/bitmap.h
> +++ b/drivers/md/bitmap.h
> @@ -253,6 +253,8 @@ int bitmap_startwrite(struct bitmap *bitmap, sector_t offset,
>  			unsigned long sectors, int behind);
>  void bitmap_endwrite(struct bitmap *bitmap, sector_t offset,
>  			unsigned long sectors, int success, int behind);
> +void bitmap_in_synced(struct bitmap *bitmap, sector_t offset,
> +			unsigned long sectors);
>  int bitmap_start_sync(struct bitmap *bitmap, sector_t offset, sector_t *blocks, int degraded);
>  void bitmap_end_sync(struct bitmap *bitmap, sector_t offset, sector_t *blocks, int aborted);
>  
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 2bf094a..bb7de94 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3622,6 +3622,8 @@ static void handle_stripe(struct stripe_head *sh)
>  	if ((s.syncing || s.replacing) && s.locked == 0 &&
>  	    test_bit(STRIPE_INSYNC, &sh->state)) {
>  		md_done_sync(conf->mddev, STRIPE_SECTORS, 1);
> +		bitmap_in_synced(conf->mddev->bitmap, sh->sector,
> +			STRIPE_SECTORS);
>  		clear_bit(STRIPE_SYNCING, &sh->state);
>  		if (test_and_clear_bit(R5_Overlap, &sh->dev[sh->pd_idx].flags))
>  			wake_up(&conf->wait_for_overlap);
> @@ -4690,6 +4692,15 @@ static inline sector_t sync_request(struct mddev *mddev, sector_t sector_nr, int
>  		return sync_blocks * STRIPE_SECTORS; /* keep things rounded to whole stripes */
>  	}
>  
> +	if (!test_bit(MD_RECOVERY_REQUESTED, &mddev->recovery) &&
> +	    conf->fullsync &&
> +	    !syncbitmap_start_sync(mddev->bitmap, sector_nr, &sync_blocks) &&
> +	    sync_blocks >= STRIPE_SECTORS) {
> +		sync_blocks /= STRIPE_SECTORS;
> +		*skipped = 1;
> +		return sync_blocks * STRIPE_SECTORS;
> +	}
> +
>  	bitmap_cond_end_sync(mddev->bitmap, sector_nr);
>  
>  	sh = get_active_stripe(conf, sector_nr, 0, 1, 0);


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  reply	other threads:[~2013-07-23  5:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  6:07 [PATCH 1/2 v2] md: add sync-bitmap to only resync WRITTEN data when adding new disk in raid array Robin Dong
2013-07-22  6:07 ` [PATCH 2/2 v2] md: set write-intent bit first in sync-bitmap for rwm in non-insync region Robin Dong
2013-07-23  5:36   ` NeilBrown [this message]
2013-07-23  5:11 ` [PATCH 1/2 v2] md: add sync-bitmap to only resync WRITTEN data when adding new disk in raid array 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=20130723153621.3f7e0eac@notabene.brown \
    --to=neilb@suse.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=robin.k.dong@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).