Re: [PATCH] i2o_block Fix, possible CFQ elevator problem?
From: Warren Togami
Date: Tue Apr 20 2004 - 04:01:33 EST
Jens Axboe wrote:
We figured removing error handling was not safe, the previous post was
only reporting test results to ask for more suggestions. I have now
tested your suggested patch above and it seems to crash in the same way
as originally.
http://togami.com/~warren/archive/2004/i2o_cfq_quad_bonnie2.txt
As a temporary safe work-around, you can apply this patch.
This makes me curious, the other elevators lacked this type of error
checking. Did this mean they were possibly allowing data corruption to
happen with buggy drivers like this? Kind of scary! We were lucky to
test this now, because this was one of the first FC kernels that
included cfq by default.
Not necessarily, it's most likely a CFQ bug. Otherwise it would have
surfaced before :-)
I forgot to mention in the previous reports:
Prior to three of your original suggested cleanups of i2o_block, four
simultaneous bonnie++'s on four independent arrays would almost
immediately cause the crash while running elevator=cfq. After those
three cleanups four simultaneous bonnie++ would survive for a while
without crashing... until you run "sync" in another terminal. We
however did not test it enough times to determine if without "sync" it
can survive the test run. Do you want this tested without "sync"?
With the deadline scheduler "sync" would take maybe 30 seconds and
return. With the cfq scheduler "sync" would be stuck there for much
longer, then trigger the crash. Markus has suspected that it crashes
when sync returns, but we have not confirmed that.
With the cfq scheduler with the error checking completely removed,
"sync" would be stuck there for a minute or more but eventually return
without crashing. (The array is reformatted between every test so we
don't really care about data corruption.)
I hope this data is helpful.
Warren Togami
wtogami@xxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/