linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shaohua Li <shli@kernel.org>
To: NeilBrown <neilb@suse.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Artur Paszkiewicz <artur.paszkiewicz@intel.com>,
	linux-raid <linux-raid@vger.kernel.org>
Subject: Re: raid5d hangs when stopping an array during reshape
Date: Wed, 24 Feb 2016 17:17:10 -0800	[thread overview]
Message-ID: <20160225011710.GA27642@kernel.org> (raw)
In-Reply-To: <87r3g1ljg7.fsf@notabene.neil.brown.name>

On Thu, Feb 25, 2016 at 11:31:04AM +1100, Neil Brown wrote:
> On Thu, Feb 25 2016, Shaohua Li wrote:
> 
> >
> > As for the bug, write requests run in raid5d, mddev_suspend() waits for all IO,
> > which waits for the write requests. So this is a clear deadlock. I think we
> > should delete the check_reshape() in md_check_recovery(). If we change
> > layout/disks/chunk_size, check_reshape() is already called. If we start an
> > array, the .run() already handles new layout. There is no point
> > md_check_recovery() check_reshape() again.
> 
> Are you sure?
> Did you look at the commit which added that code?
> commit b4c4c7b8095298ff4ce20b40bf180ada070812d0
> 
> When there is an IO error, reshape (or resync or recovery) will abort
> and then possibly be automatically restarted.

thanks pointing out this. 
> Without the check here a reshape might be attempted on an array which
> has failed.  Not sure if that would be harmful, but it would certainly
> be pointless.
> 
> But you are right that this is causing the problem.
> Maybe we should keep track of the size of the 'scribble' arrays and only
> call resize_chunks if the size needs to change?  Similar to what
> resize_stripes does.

yep, this is my first solution, but think check_reshape() is useless here
later, apparently miss the restart case. I'll go this way.

> It might also be good to put something like
>   WARN_ON(current == mddev->thread->task);
> in mddev_suspend() ... or whatever code would cause this sort of error
> to trigger a warning early.

Sounds good.

Thanks,
Shaohua

  reply	other threads:[~2016-02-25  1:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30 13:45 raid5d hangs when stopping an array during reshape Artur Paszkiewicz
2016-02-24 21:21 ` Dan Williams
2016-02-25  0:03   ` Shaohua Li
2016-02-25  0:31     ` NeilBrown
2016-02-25  1:17       ` Shaohua Li [this message]
2016-02-25 16:05         ` Artur Paszkiewicz
2016-02-25 18:42           ` Shaohua Li
2016-02-25 18:48             ` Dan Williams
2016-02-25 19:17               ` Shaohua Li
2016-02-25 19:58                 ` Dan Williams

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=20160225011710.GA27642@kernel.org \
    --to=shli@kernel.org \
    --cc=artur.paszkiewicz@intel.com \
    --cc=dan.j.williams@intel.com \
    --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 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).