Re: Reliability of bitmapped resync

[Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>]

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