AA> On 26 Apr 1999, Eric W. Biederman wrote:
>> The real gain of this is not so much in the current cases we are fast at
>> but for things like network, and compressed files (in general anything that
AA> Could you produce an example (also "look at file.c" will be ok ;) to allow
AA> me to see which are the issues with network and compressed files? Thanks.
The primary one is they can't use the buffer cache so they must roll their
own caching mechanism.
Look at the smbfs version of updatepage. (write through!)
Look at e2compr which doesn't compress data until the file is closed!
It writes the data uncompressed, and then at iput time
rewrites the file compressed.
Run a moderately early version of fat_cvf/dmsdos, before they found out how
to use the buffer cache, and watch it crawl on a read-only fs.
nfs doesn't periodically flush dirty data, to keep the volume low.
It does flush on file close (which helps, and is as correct as possible
for nfs), but you can still find
I haven't seen any provision in any of these roll your own solutions
for flushing the dirty buffers when the system is low on memory.
Etc.
The point is that because there isn't a caching subsystem
all of the filesystems above have to roll their own. And because
they roll their own the code is less polished than a solution which
would work for all of them would be.
Eric
-
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/