Coda File System

Re: Client Cache Files Limit

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Wed, 16 May 2001 16:39:13 -0400
On Tue, May 15, 2001 at 05:41:11PM +0100, Beckmann, John wrote:
> Hi,
> I have setup Coda 5.3.14 running on two servers in replicated mode, which is
> working fine. The problem I have is when I try to write more files to the
> volume than the client cache has cache files in table.
> 
> If I setup the client with a 20MB cache, venus reports that it initially has
> handles for 833 files. Does this mean that if I write more than 833 files,
> venus will lock up.

No, the client should discard not recently used files of which it knows
there is a valid copy on the servers from it's cache to make room for
the new ones.

> 13:30:51 root acquiring Coda tokens!
> Assertion failed: VDB->AllocatedMLEs < VDB->MaxMLEs, file
> "/usr/src/redhat/BUILD/coda-5.3.14/coda-src/venus/vol_cml.cc", line 519
> Sleeping forever.  You may use gdb to attach to process 5872.
> 
> Is this by design?

MLE's are Modification Log Entries, i.e. you client was operating in
disconnected or write-disconnected mode. The whole cache got filled with
modified files that were not yet on the server so it couldn't complete
the local operation.

Typically it should fail with ENOSPC when allocating the file object,
the MLE is created later on and there is no adequate error handling
anymore because most of the administration is already done and committed
and hard to revoke, the MLE just logs the change.

> This would mean that if I want to update 100,000 files, I need start venus
> with a 2.4GB cache.

Or keep the client strongly connected. To avoid server load or network
congestion to trick a client into going write-disconnected use
'cfs strong' before running the rsync. 'cfs adaptive' switches the
client back to a mode where it attempts to adapt it's behaviour as a
result of varying network connectivity.

Jan
Received on 2001-05-16 16:39:24