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 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).