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:[EMAIL PROTECTED]]
Date: mardi 23 mai 2000 16:36
À: [EMAIL PROTECTED]
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, [EMAIL PROTECTED] (315)268-1000
http://www.murkworks.com (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com AOL-IM: BKClements
