Re: Re: fr1-2.16 patch for 2.6.10 kernel

Peter T. Breuer a écrit :
> In article <[email protected]> you wrote:
> 
>>>You might want to try the obvious changes (- 1 -> - 2, twice).
>>
>>Ok, It works, Although not really clean?
> 
> 
> Well, if you can figure out the event stamping algorithm, you are a
> better man than I! 
> 
> If it only shows up on preempt and/or smp machines, I'd suspect a race
> between tamping and ejecting from the array..  Heck - it may even be a
> race anyway.

It's getting stranger and stranger! now ii seems that bitmap event count 
is incremented completly randomly

> Isn't that imposible? Urrrrrrrr ... maybe the bitmap_destr routine
> needs to _actually_ destroy the pages (hangs head in shame - I don't
> turn the bitmap off, ever ..). Hang on and I'll vamp the "remove" bit
> of the bitmap code. You need  an extra "print stats" routine anyway.
> 
> 
>>It's strange, as normally the bitmap is cleared for any successful write 
>>  during resync, but it seems that it remains untouched from a cycle to 
>>another one. Maybe a cache effect ?
> 

>>(raid1.c)
>>
>>        * on writes, clear the bitmap if all disks were written
>>          */
>>         int uptodate = test_bit(R1BIO_Uptodate, &r1_bio->state);
>>        conf_t *conf = mddev_to_conf(r1_bio->mddev);
>>
>>         /* if we should mark the bitmap clean, do so */
>>         if (uptodate && bio_data_dir(bio) == WRITE
>>                      && r1_bio->nonoperational <= 0) {
>>                 struct bitmap * bitmap = conf->bitmap;
>>                 if (bitmap && bitmap->active(bitmap)) {

I put a printk here, and it is never hit...

>>                         bitmap->clearbits(bitmap,
>>                                 bio->bi_sector >> 1, bio->bi_size >> 10);
>>                 }
>>         }