From: NeilBrown <neilb@suse.de>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: tests/03r5assemV1 issues
Date: Wed, 4 Jul 2012 15:23:27 +1000 [thread overview]
Message-ID: <20120704152327.30dcf73e@notabene.brown> (raw)
In-Reply-To: <wrfjpq8c96c9.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]
On Tue, 03 Jul 2012 18:07:02 +0200 Jes Sorensen <Jes.Sorensen@redhat.com>
wrote:
> NeilBrown <neilb@suse.de> writes:
> > On Mon, 02 Jul 2012 15:24:43 +0200 Jes Sorensen <Jes.Sorensen@redhat.com>
> > wrote:
> >
> >> Hi Neil,
> >>
> >> I am trying to get the test suite stable on RHEL, but I see a lot of
> >> failures in 03r5assemV1, in particular between these two cases:
> >>
> >> mdadm -A $md1 -u $uuid $devlist
> >> check state U_U
> >> eval $tst
> >>
> >> mdadm -A $md1 --name=one $devlist
> >> check state U_U
> >> check spares 1
> >> eval $tst
> >>
> >> I have tested it with the latest upstream kernel as well and see the
> >> same problems. I suspect it is simply the box that is too fast, ending
> >> up with the raid check completing inbetween the two test cases?
> >>
> >> Are you seeing the same thing there? I tried playing with the max speed
> >> variable but it doesn't really seem to make any difference.
> >>
> >> Any ideas for what we can be done to make this case more resilient to
> >> false positives? I guess one option would be to re-create the array
> >> inbetween each test?
> >
> > Maybe it really is a bug?
> > The test harness set the resync speed to be very slow. A fast box will get
> > through the test more quickly and be more likely to see the array still
> > syncing.
> >
> > I'll try to make time to look more closely.
> > But I wouldn't discount the possibility that the second "mdadm -A" is
> > short-circuiting the recovery somehow.
>
> That could certainly explain what I am seeing. I noticed it doesn't
> happen every single time in the same place (from memory), but it is
> mostly in that spot in my case.
>
> Even if I trimmed the max speed down to 50 it still happens.
I cannot easily reproduce this.
Exactly which kernel and which mdadm do you find it with - just to make sure
I'm testing the same thing as you?
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2012-07-04 5:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-02 13:24 tests/03r5assemV1 issues Jes Sorensen
2012-07-03 1:44 ` NeilBrown
2012-07-03 16:07 ` Jes Sorensen
2012-07-04 5:23 ` NeilBrown [this message]
2012-07-06 9:59 ` Jes Sorensen
2012-07-11 4:20 ` NeilBrown
2012-07-11 4:28 ` Roman Mamedov
2012-07-11 7:18 ` Jes Sorensen
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=20120704152327.30dcf73e@notabene.brown \
--to=neilb@suse.de \
--cc=Jes.Sorensen@redhat.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.