>Second I have noticed that the usuefullness of the
>get_hardblocksize function is, lets say, at least
>questionable. The simple logics is that:
>
>1. Why do get all the other file systems around
>without using it?
Because you can't build a 1k fs on a 2k blockdevice.
>2. At least raid and frieds basically just don't care about it if I
>understand
>the code correctly.
Because raid always uses a PAGE_SIZE blocksize and by design linux doesn't
support blockdevices with blocksizes > PAGE_SIZE.
>Removing this would make at least the quite offending two dimensional
>hardsect_size array almost a "write only" variable, which could be used
>for
>a significant overall device handling cleanup.
Of course we need to clean up this to extend the kdev_t or we'll have a
too big array but the logic must remains. If you don't know the
hardblocksize you don't know if the blocksize of the fs that you are
mounting is too big for your underying blockdevice.
>I have anyway the impression that all device drivers are emulating
>nearly
>arbitrary physical block sizes, just due to the fact that:
You can't emulate a 512kbyte softblocksize with a 2k hardblocksize.
About the patch the #defines are faster during compile and we may need
NR_REQUESTS from the outside. The compiler can't generate better code with
an inline if something it's the opposite if the compiler is lazy.
+ * Mon Nov 29 01:33:28 CET 1999 Marcin Dalecki <dalecki@cs.net.pl>:
+ *
+ * This is indeed bad, since:
+ *
+ * 1. It's heavly dependant upon the number of bits in kdev_t.
+ *
+ * 2. I miss the logical justification why exactly this (obscure) hash function
+ * should be better then anything more tangible.
What DaveM did is been to grab hardware, stress it in different ways
logging all the hash insert/remove he generated on the buffer cache. Then
he took the log and made an hashfn that was distributing the buffer heads
in the best possible way for his empirical input.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/