(Illustration by Gaich Muramatsu)
Ok, thanks Jan. I think I've understood the why "write-back cache" exists. Is this that you're saying written in any document? Does exist something like a FAQ of Coda? a) The doubt I still have is about bandwidth measurement. I'm having some problems with this. Is this working ok? b) Also, I would like to know how Coda would work with a lower "limit" ("threshold") where to decide to be "fully-connected" or "write-disconnected". In the "Coda File System User and System Administrators Manual", section 8.4.2, appears the following paragraph: ------------------------------------------------------------- Weak network connectivity. Venus uses bandwidth estimates made by the RPC2 communication layer to decide on the quality of the network connection with the servers. As soon as the connectivity to one of the servers drops to below the weakly connected treshhold (currently 50 KB/s), it will force all volumes associated with that server into weakly-connected mode. The cfs wr can be used to force the volumes back into fully connected mode, and immediately reintegrate all changes ------------------------------------------------------------- How would the client work with a this limit (currently 50KB/s) with a limit of about 10KB/s? (this mean kilobytes I think) Thanks, Juan Carlos news:20040630212241.GB28022_at_delft.aura.cs.cmu.edu... > On Thu, Jun 24, 2004 at 12:48:54PM -0300, Juan Carlos Schroeder wrote: > > Well, here it is what the "where" command in gdb prints after a crash when > > enabling "write-back" cache in venus (a venus hang) > > If you are referring to wbstart/wbauto, it never worked right work and > I'm actually slowly removing it. > > The 'wb*' functionality tried to provide connected mode semantics for > write-disconnected mode by adding special 'writeback permit' that, when > recalled by the server, forced a reintegration as soon as another client > tried to access the same volume. However for the server to see if other > clients are interested in the volume this meant that when the writeback > was granted, we needed to break the callbacks that volume on all other > clients. As a result the other clients end up spending a lot of time > trying to revalidate the local cache state, which ends up forcing > reintegration by the client with the writeback permit. > > > I forgot to say I'm using Coda Venus version 6.0.2. > > The crash happened in the RPC2 library, but you didn't mention which > rpc2 version you have installed. From the arguments it looks like it > tried to send a ViceGetWBPermit rpc call, but I don't see right now how > packing those arguments (only 4 integers) can lead to a crash. > > Jan > > >Received on 2004-07-01 10:04:59