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

In article <[email protected]> you wrote:
> > > Apr 10 09:02:35 mail-a01 kernel: raid1: skipped clean sectors 0-204799
> > 
> > This is a complete resync without rewriting anything. Looks like
> > success to me!
> 
> Yes, you are right.
> 
> Playing around with the values of /proc/sys/dev/raid/speed_limit_min I
> understood the reasons for slow/fast recovery.

OK.

> What's left is that I think the bitmap patch should not interact with the
> speed_limit as it does now.
> The problem is that the design goal of the speed_limit was to not over-stress
> the box with fast-and-resource-consuming resync. The real bad boy in resync is
> obviously the i/o stuff. But if there is no i/o taking place (like with clean
> sectors) I guess these should not count as "written" in the sense of the
> speed_limit. As there was no i/o the driver should not think he might have to
> delay to not over-stress the box.
> Do you get my idea?
> Is there a short-path to take clean sectors out of the speed_limit calculation?

Hmm.  That's what the patch does do.  It reconfigures the throttle speed
calculation to take into account the REAL i/o speed, instead of the
APPARANT i/o speed.

Clean sectors ARE taken out of the calculation. That's what the patch
does. It modifies the currspeed calculation

  currspeed = (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;

to a realspeed calculation in which skipped sectors are subtracted:

  realspeed = (j-mddev->resync_mark_cnt - atomic_read(&md_throttle[mdidx(mddev)]))/2/((jiffies-mddev->resync_mark)/HZ +1) +1;

And then the maxspeed throttle control is changed to look at realspeed
instead of currspeed:

                        if (
  #if defined(CONFIG_MD_BITMAP) || defined(CONFIG_MD_BITMAP_MODULE)
                        /* PTB use realspeed for upper limit on i/o */
                            (realspeed > sysctl_speed_limit_max) ||
  #else
                            (currspeed > sysctl_speed_limit_max) ||
  #endif /* MD_BITMAP_SUPPORT */
                                        !is_mddev_idle(mddev)) {
                                current->state = TASK_INTERRUPTIBLE;
                                md_schedule_timeout(HZ/4);
                                goto repeat;
                        }

One issue might be whether the subtracted value is correct. You might
ant to put a printk there to see if it looks sensible. The subtracted
value is zeroed in the md.c code before the personality-specific
resync-a-few-blocks request is issued, and the raid1.c code increments
the count for every block (sector?) it skips.

It looks like it is supposed to be a sector count:

   #if defined(CONFIG_MD_BITMAP) || defined(CONFIG_MD_BITMAP_MODULE)
        atomic_set(&md_throttle[mdidx(mddev)], 0);
   #endif /* MD_BITMAP_SUPPORT */
        for (j = 0; j < max_sectors;) {
                int sectors;
        
                sectors = mddev->pers->sync_request(mddev, j);

Notice that the throttle works by increasing the "nice" value of the
resync process when speed is low, and by taking a 1/4 second timeout
when speed is high. I don't know how successful that idea is in
practice. I have seen weird effects when there are several driver
layers involved (e.g. raid over loop devices on a fs on an ide disk
..).

In my experience, taking out the pause above the calculation:

                if (md_need_resched(current)) {
                /* PTB this seems not to progress when over * loop dev */
                        
                        current->state = TASK_INTERRUPTIBLE;
                        md_schedule_timeout(1);
                }

has always been helpful!


Peter