Hi, > > How it could be 55.5% dirty? Is this expected? > > This is a bug. Is fixed by a patch that I have queued for 2.6.30. As ah! OK, good to know. > I'm fairly use I have found the bug that caused the problem you first > noticed. It was introduced in 2.6.25. > Below are two patches for raid10 which I have just submitted for > 2.6.29 (As they can cause data corruption and so can jump the queue). > > The first solves your problem. The second solves a similar situation > when the bitmap chunk size is smaller. > > If you are able to test and confirm, that would be great. I downloaded a random kernel (2.6.28.7), patched with the first patch only (and the bitmap thing). Then I was lucky enough to have another HD missing at boot (sigh! It seems the PSU has a bad mood), so I could immediatly try the bitmap resync (after a second reboot, of course). It seems it worked fine. After the (relativley short) resync, I checked the array and no mismatches were found. I had only one test, I hope it is OK. There is only one thing I noticed. I was under the impression that, previously, the "dirty" bits of the bitmap were cleared during the resync, while now there were all cleared at the end. > Thanks a lot for reporting the problem and following through! Nothing, is also in my interest... :-) Thanks for the quick solution. Question about the second patch. Is it really meaningful to have the possibility of a bitmap chunk smaller than a RAID chunk? My understanding is that the data "quantum" is a RAID chunk, so why to be able to track changes at sub-chunk level? Maybe constraining the bitmap chunk to an integer multiple of the RAID chunk would help in having a simpler and cleaner code, while it will not bring big disadvantages. Just my 2 cents... bye, -- piergiorgio -- 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
