From: NeilBrown <neilb@suse.de>
To: Kerin Millar <kerframil@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: raid10 make_request failure during iozone benchmark upon btrfs
Date: Tue, 3 Jul 2012 11:39:43 +1000 [thread overview]
Message-ID: <20120703113943.3e4c43ad@notabene.brown> (raw)
In-Reply-To: <4FF10E71.2090501@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]
On Mon, 02 Jul 2012 03:58:57 +0100 Kerin Millar <kerframil@gmail.com> wrote:
> Hi Neil,
>
> On 02/07/2012 03:52, NeilBrown wrote:
> > On Mon, 02 Jul 2012 03:34:16 +0100 Kerin Millar<kerframil@gmail.com> wrote:
> >
> >> > Hello,
> >> >
> >> > I'm running a 4-way RAID-10 array with the f2 layout scheme on a 3.5-rc5
> > I thought I fixed this in 3.5-rc2.
> > Maybe there is another bug....
> >
> > Could you please double check that you are running a kernel with
> >
> > commit aba336bd1d46d6b0404b06f6915ed76150739057
> > Author: NeilBrown<neilb@suse.de>
> > Date: Thu May 31 15:39:11 2012 +1000
> >
> > md: raid1/raid10: fix problem with merge_bvec_fn
> >
> > in it?
>
> I am indeed. I searched the list beforehand and noticed the patch in
> question. Not sure which -rc it landed in but I checked my source tree
> and it's definitely in there.
>
> Cheers,
>
> --Kerin
Thanks.
Looking at it again I see that it is definitely a different bug, that patch
wouldn't affect it.
But I cannot see what could possibly be causing the problem.
You have a 256K chunk size, so requests should be limited to 512 sectors
aligned at a 512-sector boundary.
However all the requests that a causing errors are 512 sectors long, but
aligned on a 256-sector boundary (which is not also 512-sector). This is
wrong.
It could be that btrfs is submitting bad requests, but I think it always uses
bio_add_page, and bio_add_page appears to do the right thing.
It could be that dm-linear is causing problem, but it seems to correctly after
the underlying device for alignment, and reports that alignment to
bio_add_page.
It could be that md/raid10 is the problem but I cannot find any fault in
raid10_mergeable_bvec - performs much the same tests that the
raid01 make_request function does.
So it is a mystery.
Is this failure repeatable?
If so, could you please insert
WARN_ON_ONCE(1);
in drivers/md/raid10.c where it prints out the message: just after the
"bad_map:" label.
Also, in raid10_mergeable_bvec, insert
WARN_ON_ONCE(max < 0);
just before
if (max < 0)
/* bio_add cannot handle a negative return */
max = 0;
and then see if either of those generate a warning, and post the full stack
trace if they do.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-07-03 1:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 2:34 raid10 make_request failure during iozone benchmark upon btrfs Kerin Millar
2012-07-02 2:52 ` NeilBrown
2012-07-02 2:58 ` Kerin Millar
2012-07-03 1:39 ` NeilBrown [this message]
2012-07-03 2:13 ` Kerin Millar
2012-07-03 2:47 ` NeilBrown
2012-07-03 15:08 ` Chris Mason
2012-07-07 17:29 ` Kerin Millar
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=20120703113943.3e4c43ad@notabene.brown \
--to=neilb@suse.de \
--cc=kerframil@gmail.com \
--cc=linux-raid@vger.kernel.org \
/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.