Re: fr1-2.16 patch for 2.6.10 kernel

In article <[email protected]> you wrote:
> > There's a call to import_device about 20 lines higher up that might do
> > instead. It has a -1 in the args that means "don't retest the
> > superblock". If it is changed to 0, it might also work the trick.
> 
> Ok, it does the job too.

Good.

> about events :
> 
> md0: repairing old mirror component 800001 (disk 356 >= bitmap 232)
> md0: new disk 800001 too old for repair (disk 360 < bitmap 362)
> 
> 
> mount has changed the bitmap count ?

It should not. The bitmap count is set when the bitmap is activated and
not changed. If it is disactivated and then reactivated, it copies the
superblock count.

> md0: repairing old mirror component 800001 (disk 370 >= bitmap 362)
> md0: repairing old mirror component 800001 (disk 374 >= bitmap 362)

> same as above : bitmap not cleared ?

Looks like some separate problem - it should be cleared after a resync
has occured.  I can look at it in a moment (this is easy).

> md0: repairing old mirror component 800001 (disk 400 >= bitmap 362)

> raid1: synced dirty sectors 0-511
> raid1: skipped clean sectors 512-122495
> raid1: synced dirty sectors 122496-122751
> raid1: skipped clean sectors 122752-490239
> raid1: synced dirty sectors 490240-491007
> raid1: skipped clean sectors 491008-979711
> 
> ... and so on, no changes.
> 
> The latter are interesting, because raid is not mounted, so it seems 
> that it reuse the bitmap from previous cycle and doesn't detect that 
> nothing has changed on disks and reinitialize bitmap. It is not harmful, 

The bitmap should be cleared by successful resyncs. It's possible to
imagine some failures however, particularly if the disk was once faulted
out again during a resync.  Then it's hard to see how the counts could
get easily back into sync .

> but clearly suboptimal, especially in case of network devices, as large 
> chunks of disks may be synced multiple times.

Sure - I'll look at it. I would guess that it's a matter of
having forgotten to clean the bitmap pages as they are gotten, or
redispensed, so that any initial marks on them are not cleared even by
resync. I recall having had that bug once, and it may have resurfaced.

See this in bitmap.c:

static unsigned char *
bitmap_alloc_page(struct bitmap *bitmap) {
        unsigned char *page;

        page = kmem_cache_alloc(bitmap_page_cache, GFP_KERNEL);
        /* PTB zeroing is done by the constructor and only
         *     clean pages are returned to the cache
         */
        return page;
 }

Well, maybe that comment is no longer accurate. Add a

      memset(page, 0, PAGE_SIZE);

before the return.

Peter