On 10/19/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> On Friday October 19, [EMAIL PROTECTED] wrote:
> > I'm using a stock 2.6.19.7 that I then backported various MD fixes to
> > from 2.6.20 -> 2.6.23... this kernel has worked great until I
> > attempted v1.0 sb w/ bitmap=internal using mdadm 2.6.x.
> >
> > But would you like me to try a stock 2.6.22 or 2.6.23 kernel?
>
> Yes please.
> I'm suspecting the code in write_sb_page where it tests if the bitmap
> overlaps the data or metadata. The only way I can see you getting the
> exact error that you do get it for that to fail.
> That test was introduced in 2.6.22. Did you backport that? Any
> chance it got mucked up a bit?
I believe you're referring to commit
f0d76d70bc77b9b11256a3a23e98e80878be1578. That change actually made
it into 2.6.23 AFAIK; but yes I actually did backport that fix (which
depended on ab6085c795a71b6a21afe7469d30a365338add7a).
If I back-out f0d76d70bc77b9b11256a3a23e98e80878be1578 I can create a
raid1 w/ v1.0 sb and an internal bitmap. But clearly that is just
because I removed the negative checks that you introduced ;)
For me this begs the question: what else would
f0d76d70bc77b9b11256a3a23e98e80878be1578 depend on that I missed? I
included 505fa2c4a2f125a70951926dfb22b9cf273994f1 and
ab6085c795a71b6a21afe7469d30a365338add7a too.
*shrug*...
Mike
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
