On 10/19/07, Neil Brown <neilb@xxxxxxx> wrote: > On Friday October 19, snitzer@xxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
