linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jianpeng Ma" <majianpeng@gmail.com>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: Re: [PATCH] raid5: Avoid doing more read on dev of a stripe at the same time
Date: Thu, 20 Sep 2012 14:04:54 +0800	[thread overview]
Message-ID: <2012092014045245356613@gmail.com> (raw)
In-Reply-To: 20120920132422.0f7841f1@notabene.brown

On 2012-09-20 11:24 NeilBrown <neilb@suse.de> Wrote:
>On Thu, 20 Sep 2012 11:04:46 +0800 "Jianpeng Ma" <majianpeng@gmail.com> wrote:
>
>> On 2012-09-20 10:51 NeilBrown <neilb@suse.de> Wrote:
>> >On Sat, 15 Sep 2012 10:20:35 +0800 "Jianpeng Ma" <majianpeng@gmail.com> wrote:
>> >
>> >> In func 'ops_run_bio' if you read the dev which the last reading
>> >> of this dev didn't return,it will destrory the  req/rreq'source of rdev.
>> >> It may call hung-task.
>> >> For example, for badsector or other reasons, read-operation only used
>> >> stripe instead of chunk_aligned_read.
>> >> First:stripe 0;second: stripe 8;third:stripe 16.At the block-layer,three
>> >> bios merged.
>> >> Because media error of sector from 0 to 7, the request retried.
>> >> At this time, raid5d readed stripe0 again.But it will set 'bio->next =
>> >> NULL'.So the stripe 8 and 16 didn't return.
>> >> 
>> >> Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
>> >
>> >Hi,
>> > I'm really trying, but I cannot understand what you are saying.
>> >
>> Sorry for my bad english.
>> >I think the situation that you are describing involves a 24 sector request.
>> >This is attached to 3 stripe_heads - 8 sectors each - at address 0, 8, 16.
>> >
>> >So 'toread' on the first device of each stripe points to this bio, and
>> >bi_next is NULL.
>> >
>> >The "req" bio for each device is filled out to read one page and these three
>> >'req' bios are submitted.  The block layer merges these into a single request.
>> >
>> >This request reports an error because there is a read error somewhere in the
>> >first  8 sectors.
>> >
>> Yes,
>> >So one, or maybe all, of the 'req' bios return with an error?
>> From my test, when req did not return and at the same time, the bio(stripe 0) send.
>> So this operation will set bi_next is NULL.
>
>Are you saying that we send another bio before the first one has returned?
>That shouldn't be possible as sh->count will prevent it from happening.
>While there is an outstanding request, sh->count will be >0, and until
>sh->count is 0, we won't try to send any more requests.
>

>So I still don't understand.  Please try to provide as much detail as
>possible.  If it is easier, write in your own language and use
>translate.google.com to convert to english. ??
>
Because my disks which had badsector wrote and can't reproduce this bug now.
1: create raid5 
	mdadm -CR /dev/md0 -l5 -c4 -n4 missing /dev/sd[cde] 
	sdb and sdc  had badsectors.
2:do read operation 
  while true;do
  dd if=/dev/md0 of=/dev/null bs=3M count=1 oflag=direct
  done
3:dd will be hang.

Suppose read stripeN from missed disk, it only read disk sdc/sdd/sde and to computer.
1: first send read operation about sdc/sdd/sde for computer
2: then read sdc through chunk_aligned_read and met error and used stripe to read.
If this read-operation can add stripe and send to sdc,there is chance to occur the problem like explained.


  reply	other threads:[~2012-09-20  6:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-15  2:20 [PATCH] raid5: Avoid doing more read on dev of a stripe at the same time Jianpeng Ma
2012-09-20  2:51 ` NeilBrown
2012-09-20  3:04   ` Jianpeng Ma
2012-09-20  3:24     ` NeilBrown
2012-09-20  6:04       ` Jianpeng Ma [this message]
2012-09-21  2:24       ` Jianpeng Ma
2012-09-25  7:29         ` NeilBrown
2012-09-26  2:43           ` NeilBrown
2012-09-26  4:09             ` Jianpeng Ma
2012-09-26  9:14             ` Jianpeng Ma

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=2012092014045245356613@gmail.com \
    --to=majianpeng@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 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).