Re: fr1-2.16 patch for 2.6.10 kernel

In article <[email protected]> you wrote:
> Peter T. Breuer a ?crit :
> >>can you please send me your current fr1 patch to be sure that we are on
> >>sync (or confirm that the ftp one is the good one)?
> > 
> > I've just generated the patch for the code I am using. I haven't
> > compared with the archive. It looks about the same (I just read through
> > it to make sure it looks sensible).
> > 
> > Apologies if I forgot any file.
> 
> Ok, i tested with your patch : no crash!  but alway this stange behavior 

But as you noticed, there is no substantial difference between what I
sent you and the patch in the archive. I had merely tidied a few
stanzas.


> : from time to time, faulty disk is not recognised, forcing total 

Yes, I kno about that - we have seen it. The UUID read is not right.

> md: export_rdev(sda1)
> md 1205: unlock_rdev nulls bdev
> md 1197: lock_rdev restores bdev 800001
> md: adding new mirror component 800001
> md: old uuid 5dc1267b 788f7499 cd49d3c0 d06f0b96
> md: new uuid 0 8048640 2 400179c8 <***** disk has changed.

Yes. But please put this printout further up, before the "if" that tests
equality. Grep for "new uuid" in md.c. Then we will see when it is
right as well as wrong!

>   disk 1, wo:0, o:1, dev:sdb1
> md: syncing RAID array md0 (sb f7fc8480)
> md: minimum _guaranteed_ reconstruction speed: 10000000 KB/sec/disc.
> md: using maximum available idle IO bandwith (but not more than 200000 
> KB/sec) for reconstruction.
> md: using 128k window, over a total of 489856 blocks.
> md0: no repair bit on sb so removed bitmap f7cbb740
> 
> total resync here.

Indeed, but it matches what it sees. Why it sees a different uuid is
the question. Maybe something writes sb data in the wrong place? Or
reads it from the wrong place?

Peter