The file write-back to the server could also include an intelligent way to send data, ala rsync (http://samba.anu.edu.au/rsync/) : only modified portions of the files are transfered from the client to the server. Thus applications that open files for writing , and do not modify them, will benefit greatly from that : no file transfer at all will occurs (after checksuming the files).
This only involves the file transfert, not logging or anything else, and the code is already done and greatly working in rsync.

Nicolas Huillard

-----Message d'origine-----
De:	Brad Clements [SMTP:bkc_at_murkworks.com]
Date:	mardi 23 mai 2000 16:36
Objet:	Re: performance

On 22 May 2000, at 16:16, Jan Harkes wrote:

> NFS/Samba have a completely different model, they are block based. If
> you read a very large uncached file in Coda, you have to wait until it has
> been fetched completely. Once it is in the cache, read/write access is
> pretty much similar to local disk speed. So if you are doing several sweeps
> through a 500MB file, the others will really suck.
> 
> On the other hand, if you read that file just once and never ever look at
> it again (i.e. unpacking a tarball), filesystems like NFS are more likely
> to be useful.

I think it would be an interesting research project to support "trickle read 
ahead". Where portions of the file that are requested are returned (if 
cached), while the file is read from the server by the cache manager in 
the background. For small files, this probably won't buy much, but for 
large files it might be useful, especially if the cache manager can 
request file sections from the server, while trickling in the rest of the file. 

> We always send back a file that has been opened for writing, any sane
> application (except for Win95 ones) only opens for reading if they

Is this true even if no write operation has taken place on the file? 
Perhaps the application opened the file for the possibility of writing, but 
in the end did not write() to the file at all. Do you send the file back to 
the server then?



Brad Clements,                bkc_at_murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               AOL-IM: BKClements