On Thu, Feb 19, 2004 at 12:11:10PM -0600, Jason A. Pattie wrote:
> What does that mean?  I suppose that's why it's taking quite awhile to
> transfer the 580MB of data into the coda volume?

It means that your client is write-disconnected and performing more
operations faster than it can reintegrate with the server. If we didn't
slow down the writes, your client would end up using up the rest of the
reintegration log quite quickly and most likely crash. If your client is
not reintegration at all (possibly caused by a conflict) it will at some
point reach the 'red zone' and block any mutating operations. This is
pretty fatal in itself, because each blocked operation will use up a
worker thread and there are only about 20 of those.

> I did an 'cfs strong' command, but that didn't change anything.  Is it
> possible that the cache is getting full (only 400MB) and needs to purge
> least recently used entries or something and so it's taking lots of time?

I've said this many times before, there is no such thing as guaranteed
connected operation in Coda. If anything goes wrong during a write/store
operation the client will silently switch to write-disconnected
operation (logging state). If the server is slow to respond we switch to
a logging state. And reversely, when the client can't be reached by the
server, the server triggers the disconnect were are likely to switch to
a logging state.

The only thing that cfs strong does is prevent the client from listening
to the often incorrect 'bandwidth estimates' from the RPC2 communication
layer, so that transitions only happen in error cases and not based on
incorrect estimates. In fact, if you were already write-disconnected
before calling cfs strong, the client will never discover that the
network actually has good bandwidth and will never transition to the
connected state.

Jan