Hello,

Linux 2.6 has always been flaky with regard to concurrent file system
access races. Coda can easily trigger this. I guess it is "optimization"
shortcuts in the kernel (not in Coda) who cause this.

A move from 2.6.26 to 2.6.32 happens to make the races much more
pronounced. My environment is run from Coda and I notice e.g. that
running a loop with about 800 ls|tail commands produces around a dozen
"sh: /coda/..../ls: No such file or directory" messages.

The file is of course actually present there and most of the time is run fine.

It is in the first hand sh pipelines which exhibit the problem,
in other words parallel lookups on Coda due to execve() and open()
on the libraries.

Anybody here who can guess where in the kernel the problem lies, to talk
to the developers? Today Linux 2.6 moves from being not totally reliable
to quite unusable with Coda in certain setups. That's really disturbing.

Regards,
Rune