Hi,

quoted

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