Re: 2.6.24-rc6 reproducible raid5 hang

[Neil Brown <neilb@suse.de>]

On Thursday January 10, dan.j.williams@gmail.com wrote:
> On Jan 10, 2008 12:13 AM, dean gaudet <dean@arctic.org> wrote:
> > w.r.t. dan's cfq comments -- i really don't know the details, but does
> > this mean cfq will misattribute the IO to the wrong user/process?  or is
> > it just a concern that CPU time will be spent on someone's IO?  the latter
> > is fine to me... the former seems sucky because with today's multicore
> > systems CPU time seems cheap compared to IO.
> >
> 
> I do not see this affecting the time slicing feature of cfq, because
> as Neil says the work has to get done at some point.   If I give up
> some of my slice working on someone else's I/O chances are the favor
> will be returned in kind since the code does not discriminate.  The
> io-priority capability of cfq currently does not work as advertised
> with current MD since the priority is tied to the current thread and
> the thread that actually submits the i/o on a stripe is
> non-deterministic.  So I do not see this change making the situation
> any worse.  In fact, it may make it a bit better since there is a
> higher chance for the thread submitting i/o to MD to do its own i/o to
> the backing disks.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>

Thanks.
But I suspect you didn't test it with a bitmap :-)
I ran the mdadm test suite and it hit a problem - easy enough to fix.

I'll look out for any other possible related problem (due to raid5d
running in different processes) and then submit it.

Thanks,
NeilBrown