Re: Re: patch fr1-2.17 does not work with kernel 2.4.30

On Mon, 11 Apr 2005 13:36:04 +0200 (MET DST)
"Peter T. Breuer" <[email protected]> wrote:

> "Also sprach Stephan von Krawczynski:"
> > On Sun, 10 Apr 2005 19:59:51 +0200 (MET DST)
> > "Peter T. Breuer" <[email protected]> wrote:
> > 
> > > Try changing 27 to 26. Recompile all md modules.
> > 
> > I tried that, but that did make no difference at all. All output looks
> > quite the same and the "hotadd" is a complete resync.
> 
> There's no point in looking at that. Confirm the call to start.
> 
> > Still there is no call to bitmap->start.
> 
> I'm afraid there is! I showed you my trace:
> 
>    md: set_disk_faulty
>    md: md_error
>    raid1: raid1_error
>    raid1: mark_disk_bad
>    raid1: raid1_start_bitmap
>    raid1: made bitmap a027dc20 at events 7
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    raid1: Disk failure on ubd/disc2/disc, disabling device. 
>            Operation continuing on 1 devices
> 
> The sequence is directly executed from hotsetfaulty.
> 
> > The output still tells me that the
> > bitmap XXXX is "already active!".
> 
> Then it has been started some time in the past.
> 
> > This is the code right before bitmap->start.
> > It seems never "started" but always "active", right from the beginning ...
> 
> It does not seem - it is started.  If the test says it is already
> active, then that is GOOD.  There is nothing wrong.  You can see:
> 
>   static int
>   raid1_start_bitmap (mddev_t *mddev) {
>   ...
> 
>   if (bitmap->active(bitmap)) {
>             printk(KERN_WARNING "raid1: bitmap %x already active!\n",
>                     (unsigned) bitmap);
>             return 0;
>             ^^^^^^^^^ SUCCESS!
>   }
> 
> If it isn't already active, then it starts it, but if it is active,
> then there is nothing that needs doing. If you want to see where it is
> started you will have to look earlier in your trace. But there is no
> urgent need to worry.

Hello Peter,

well, in fact I am pretty worried. And the reason is simple:
There is _no_ way around a printk. If it is not in the logs, then there was no
call. point.
But what I really do not understand is this:
Why does the same hardware (and software) show this in non-persistent case:

kernel: md: syncing RAID array md0
kernel: md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc.
kernel: md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction.
kernel: md: using 124k window, over a total of 25679900 blocks.
kernel: md0: retained bitmap f6e57180
kernel: raid1: skipped clean sectors 0-51359799
kernel: md: md0: sync done.

Whereas the persistent case looks like:

kernel: md: syncing RAID array md0
kernel: md: minimum _guaranteed_ reconstruction speed: 100 KB/sec/disc.
kernel: md: using maximum available idle IO bandwith (but not more than 100000 KB/sec) for reconstruction.
kernel: md: using 124k window, over a total of 25679808 blocks.
kernel: md0: removed bitmap f6630900
kernel: raid1: synced dirty sectors 0-51359615  
kernel: md: md0: sync done.


This is completely reproducable and I really can mkraid the thing 10 times flipflopping the persistence. Persistent-case always removes the bitmap, non-persistent always retains it.

Where is the difference regarding bitmap-handling between the two?

Regards,
Stephan