Messages in this thread | | | Date | Wed, 13 Sep 2000 03:26:32 +0200 | From | Martin Dalecki <> | Subject | Re: elevator code |
| |
"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/
| |