Alan Cox wrote:
>>I still don't think maintainig this array is worth just for hfs
>>readahead, so the below patch disables it and gets rid of read_ahead.
>>
>>Jens, could you check the patch and include it in your next batch of
>>block-layer changes for Linus?
>>
>
>What would be significantly more useful would be to make it actually work.
>Lots of drivers benefit from control over readahead sizes - both the
>stunningly slow low end stuff and the high end raid cards that often want
>to get hit by very large I/O requests (eg 128K for the ami megaraid)
>
No you are wrong. This array is supposed to provide a readahead setting
on the driver level, which is bogous, since
it's something that *should* not be exposed to the upper layers at all.
Please note as well that
we have already max_readahead in struut block_device as well. Please
note that this array only has
a granularity of major block device numbers which is compleatly bogous
for example for a disk and
cd-rom hanging on a IDE interface. And so on and so on... It's really
better to let it go.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:33 EST