On Tuesday May 30, [EMAIL PROTECTED] wrote:
> On Wed, 31 May 2006, Neil Brown wrote:
>
> > On Tuesday May 30, [EMAIL PROTECTED] wrote:
> > >
> > > actually i think the rate is higher... i'm not sure why, but klogd
> > > doesn't
> > > seem to keep up with it:
> > >
> > > [EMAIL PROTECTED]:~# grep -c kblockd_schedule_work /var/log/messages
> > > 31
> > > [EMAIL PROTECTED]:~# dmesg | grep -c kblockd_schedule_work
> > > 8192
> >
> > # grep 'last message repeated' /var/log/messages
> > ??
>
> um hi, of course :) the paste below is approximately correct.
>
Ok, so thousands of times a second. Not what I expected at all...
So I read the code more carefully, and can see that patch was all
wrong. It might actually make the problem go away, but isn't really
the right fix.
I think I will be able to suggest a fix which should work a be a
reasonable thing to do, but it still won't help me understand the
problem.
I've got one more long-shot I would like to try first. If you could
backout that change to ll_rw_block, and apply this patch instead.
Then when it hangs, just cat the stripe_cache_active file and see if
that unplugs things or not (cat it a few times).
If it does, I think I am on to the problem.
If it doesn't I'll give up and give you a patch that should work
around the problem in a reasonable way.
Thanks,
NeilBrown
Signed-off-by: Neil Brown <[EMAIL PROTECTED]>
### Diffstat output
./drivers/md/raid5.c | 3 +++
1 file changed, 3 insertions(+)
diff ./drivers/md/raid5.c~current~ ./drivers/md/raid5.c
--- ./drivers/md/raid5.c~current~ 2006-05-28 21:56:56.000000000 +1000
+++ ./drivers/md/raid5.c 2006-06-01 12:44:52.000000000 +1000
@@ -1840,6 +1840,9 @@ stripe_cache_active_show(mddev_t *mddev,
spin_unlock_irq(&conf->device_lock);
n += sprintf(page+n, "bitlist=%d delaylist=%d\n", c1, c2);
trigger = 0xffff;
+
+ /* incredible long shot... */
+ kblockd_flush();
return n;
} else
return 0;
-
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