No we shouldn't.
There are the following problems with the read_ahead array as it
currently
stands:
1. It isn't used at all at any level!
Even the AS390 people finally cleaned aparently theyr code up.
REALY REALY Please look at the the patch.
There is only one bogous place in hfs, where this array was used at all.
Literally all other places are just writing some values into it.
This is what I'm calling a "write only" variable.
2. It is bound to the major number, which is the wrong granularity,
since linux doesn't preserve the device type on this level and is
slicing up
the minor numbers. This is the most severe brain damage of it.
3. We have anyway a filesystem read ahead layer there.
4. We have a block device driver read ahead layer there too
(it's called blksize there...).
5. We have blk_dev_t and block_device structs, which are supposed
to replace the current static global array, since they are the
more logical place where such information should be placed. This
is unevitable if we are ever willing to provide support for real
kernel scalability in terms of numbers of attached devices...
Regard's.
-
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/