All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: NeilBrown <neilb@suse.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [md PATCH 1/3] md/raid1: fix: IO can block resync indefinitely
Date: Wed, 9 Nov 2016 12:50:36 -0800	[thread overview]
Message-ID: <20161109205036.6do6roypkhpbyv2n@kernel.org> (raw)
In-Reply-To: <147864729272.1076.727849896269121517.stgit@noble>

On Wed, Nov 09, 2016 at 10:21:32AM +1100, Neil Brown wrote:
> While performing a resync/recovery, raid1 divides the
> array space into three regions:
>  - before the resync
>  - at or shortly after the resync point
>  - much further ahead of the resync point.
> 
> Write requests to the first or third do not need to wait.  Write
> requests to the middle region do need to wait if resync requests are
> pending.
> 
> If there are any active write requests in the middle region, resync
> will wait for them.
> 
> Due to an accounting error, there is a small range of addresses,
> between conf->next_resync and conf->start_next_window, where write
> requests will *not* be blocked, but *will* be counted in the middle
> region.  This can effectively block resync indefinitely if filesystem
> writes happen repeatedly to this region.

Good catch, thanks Neil! 
> As ->next_window_requests is incremented when the sector is before

I changed 'before' to 'after' when applying this patch

Thanks,
Shaohua

  reply	other threads:[~2016-11-09 20:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-08 23:21 [md PATCH 0/3] Three unrelated md patches NeilBrown
2016-11-08 23:21 ` [md PATCH 1/3] md/raid1: fix: IO can block resync indefinitely NeilBrown
2016-11-09 20:50   ` Shaohua Li [this message]
2016-11-08 23:21 ` [md PATCH 2/3] md: remove md_super_wait() call after bitmap_flush() NeilBrown
2016-11-09 20:51   ` Shaohua Li
2016-11-10  0:57     ` NeilBrown
2016-11-10  1:13       ` Shaohua Li
2016-11-08 23:21 ` [md PATCH 3/3] md: define mddev flags, recovery flags and r1bio state bits using enums NeilBrown
2016-11-09 20:52   ` Shaohua Li

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=20161109205036.6do6roypkhpbyv2n@kernel.org \
    --to=shli@kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.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 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.