(Illustration by Gaich Muramatsu)
On Mon, Feb 18, 2002 at 06:23:55AM +0100, Rene Rebe wrote: > > As long as the client remains disconnected, it won't 'really' discard > > the user's tokens so that you continue to have whatever access > > permissions were cached at the time of disconnection. > > This doesn't seem to be as user-firendly as the "weekend trip" stories > in all the CODA paper suggest ;-)! - I'll take a look ... Ehh, how often do you reboot your laptop? I typically just suspend it and only reboot once every 2/3 weeks for a kernel upgrade. > > > 3. The read performance seem to be arround 2 MB/s which is ok for the > > > beginning - but the write porformance seems to be arround 150kB/s > > > which is slightly too slow ... Any ideas? > > > > Ehhh, how did you measure write performance? Every operation that is > > By takeing a look to the network-traffic ;-). A little correction: For > reads I get 4-5MB/s from the server. For reintegration (after writes > in disconnected mode) venus trasmits 4-5MB/s to the server. But for > connected writes I only get 150kB/s and the processing that is writing > hangs until the transmission has finished. Doesn't venus sends the > whole file after the write has completely finished? And shouldn't this > happen in the same speed? And why is the writing process blocking > during this operation? Venus only writes the data back when the file is closed, i.e. all writes have completed. After that it should be the same speed, however SFTP (the bulk data transport) is a strange beast and such an asymmetry somehow doesn't surprise me too much, the last time I checked we could write at 3MB/s to a triply replicated volume (i.e. pushing 9MB/s out on the network), but got about 2MB/s to a doubly replicated volume (for a total of 4MB/s). There is some really funny timing going on and it turned out to be hard to tune. The current settings seemed to be the 'best' for various networks I tested, 33k6 dialup, 10base-T and a simulated ad-hoc wireless 2MB/s network, while contacting doubly and triply replicated servers. JanReceived on 2002-02-18 00:54:40