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
>
>
>