Am Donnerstag, 27. April 2006 22:12 schrieb Jan Harkes:

Hi Jan,

thank you for your prompt reply.

> I don't really see how there could be a problem. Our userspace cache
> manager only sees open and close operations, so the individual writes
> are going directly to the underlying filesystem where the cached files
> are stored.
>
> Then when the file is closed, an upcall is queued for venus, the
> queueing in the kernel (as well as the volume locks that is taken in
> userspace) will effectively serialize all those close operations.
>
> Are you sure your client isn't simply going into write-disconnected mode?

I can't find anything in the Log-Files, indicating this.

> In any case, run 'codacon', it will show a lot of more transient
> messages that are not logged to logfiles which will be helpful in
> determining what the client is doing.

Unfortunately codacon only shows bandwidth- and BackProbe-Messages after this 
error occurs.

> You can also check volume status with 'cfs lv /coda/path/to/volume' this
> will, amongst other things, show connectivity status of the volume.

cfs checkservers: says that all servers are up
cfs lv: does nothing and hangs like all other tasks that try to access the 
Codafilesystem.

I tried to reproduce the failure on two different machines. It also occured 
with Version 6.0.10 on Gentoo with kernel 2.6.15-suspend2-r8, and even on 
2.4.32-coda it didn't respond.

Perhaps I use a very weird configuration, but I generated one with 
vice-setup / venus-setup, thus I think it's nothing special.

If a developer is interested I would be glad to send my script and 
instructions on usage, since I can reliable reproduce this error with this 
script on my machines.

Marcel