On Tue, Jan 02, 2001 at 11:35:54AM -0700, Matt Peterson wrote:
> Another thing you should realize is that Coda does not use kernel level
> threads... at least I don't think it does (yet).  This means that Coda
> will not be able to balance CPU load across multiple processors.  This
> is one reason (at least for us) that Coda is not ready for full
> production environment.

Ofcourse it doesn't even need kernel level threads, as it uses the
userspace context to do it's work. For most operations, when an
operation enters the kernel a big lock is taken in the VFS layer, before
we even get into the Coda FS module, this happens for _every_ filesystem.

Then there are some minimal checks being done to see whether the request
can be serviced without contacting userspace. If so, we're done.
Otherwise a relatively expensive upcall has to be made to the userspace
cachemanager. We post the upcall, put ourselves on a waitqueue and
_release_ the big lock. This way other user processes can get into the
VFS while the cachemanager is working on our request.

We actually need to allow multiple processes into the VFS while waiting,
otherwise the cachemanager can't even create the containerfile that
needs to be passed back to the kernel.

Coda will definitely balance the load across multiple CPU's as far as
filesystem requests are concerned. What it doesn't do is use multiple
CPU's for the cachemanager, which is really not as bad as it sounds.

> As for stability, I have not hard evidence that Coda is not stable
> enough for production environments -- though I still feel really good
> that our Coda filesystem is frequently backed up.

Over the past year or so we haven't had to go back to backups for Coda
failures very often, but more because of `user failure': "I thought that
file wasn't imporant, and removed it".

Jan