On Thursday May 10, [EMAIL PROTECTED] wrote:
> 
> On May 10 2007 16:22, NeilBrown wrote:
> >
> >diff .prev/drivers/md/md.c ./drivers/md/md.c
> >--- .prev/drivers/md/md.c    2007-05-10 15:51:54.000000000 +1000
> >+++ ./drivers/md/md.c        2007-05-10 16:05:10.000000000 +1000
> >@@ -5095,7 +5095,7 @@ static int is_mddev_idle(mddev_t *mddev)
> >              *
> >              * Note: the following is an unsigned comparison.
> >              */
> >-            if ((curr_events - rdev->last_events + 4096) > 8192) {
> >+            if ((long)curr_events - (long)rdev->last_events > 4096) {
> >                     rdev->last_events = curr_events;
> >                     idle = 0;
> >             }
> 
> What did really change? Unless I am seriously mistaken,
> 
>     curr_events - last_evens + 4096 > 8192
> 
> is mathematically equivalent to
> 
>     curr_events - last_evens        > 4096
> 
> The casting to (long) may however force a signed comparison which turns
> things quite upside down, and the comment does not apply anymore.

Yes, the use of a signed comparison is the significant difference.
And yes, the comment becomes wrong.  I'm in the process of redrafting
that.  It currently stands at:

                /* sync IO will cause sync_io to increase before the disk_stats
                 * as sync_io is counted when a request starts, and 
                 * disk_stats is counted when it completes.
                 * So resync activity will cause curr_events to be smaller than
                 * when there was no such activity.
                 * non-sync IO will cause disk_stat to increase without
                 * increasing sync_io so curr_events will (eventually)
                 * be larger than it was before.  Once it becomes
                 * substantially larger, the test below will cause
                 * the array to appear non-idle, and resync will slow
                 * down.
                 * If there is a lot of outstanding resync activity when
                 * we set last_event to curr_events, then all that activity
                 * completing might cause the array to appear non-idle
                 * and resync will be slowed down even though there might
                 * not have been non-resync activity.  This will only
                 * happen once though.  'last_events' will soon reflect
                 * the state where there is little or no outstanding
                 * resync requests, and further resync activity will
                 * always make curr_events less than last_events.
                 *
                 */


Does that read at all well?

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to