"Jeff V. Merkey" wrote:
>
> Martin,
>
> I'm glad you are not still mad at me. :-) I hope this info was
> helpful.
Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the same lessons at Sun or
Berkeley? ;-)
The most important fact is that there is no misconception of blocks like
there is currently under Linux. Linux is basically using FOUR different
block
concepts in case of the block device handling:
1. Filesystem iduced blocks.
2. physical block size.
3. buffer block size.
Where in fact there should be only two:
1. FS block
2. physical block size.
Merging 2. and 3. should be handled on the driver level.
Interrestingliy enough the driver writers do it "intuitively"
very freqeuntly indeed (ATAPI cd or mcdx for example). However they get
beaten by the fact that sometimes the dividing
line even between 1. and 2. isn't clean unter linux ;-)... insead of
just
basing anything on a basic buffer block size like 512 bytes.
Interrestingly there is the same overgranulation in the concept of
read-ahead under linux:
1. VFS read write - ahead.
1b. FS specific read write ahead.
2. Driver read write -ahead.
3. Physical device cache read write -ahead.
Once again at least one point too much.... and then you could see
the elevator as even just
4. some kind of wired variable block write/read-ahead...
In fact most of the read aheads above are just foo due to the fact
that the one enumerated as 3. is aleviating them.
However due to "code impedancy", in esp. driver code impedancy I doubt
seriously this will get ever cleaned up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:19 EST