Coda File System

Re: strange tests with coda

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 19 Nov 1999 10:58:55 -0500
On Fri, Nov 19, 1999 at 03:34:02PM +0100, Emmanuel Anne wrote:
> I tried to mount a simple server to make some tests on it.
> Log file = 12M (in a file /log)
> data file = 44M (in a file /data)
> 
> Mounted with venus-setup <host> 10000
> df returns stupid results for the coda parition... (server and client run on
> linux).

That's either 9GB/9GB/9GB (before Linux 2.2.11)
Or df:    <size of client cache>/<blocks associated with write open objects>/
	    <free-able blocks>
   df -i: <available fso's>/<allocated fso's>/<free fso's> (2.2.11 and later)

> And I finally receive "No space left on device" avec having put only
> about 88 M on it (22M little files and one 66M big file).

Ok, ENOSPC can come from different parts of the system-`chain'. Alas,
there is only one ENOSPC, so it's meaning is a bit overloaded.

1 Server partition full.
    For replicated volumes any of the partitions with one of the
    replicas is full

2 The client cache is full (diskblocks),
    this can only happen when no objects can be flushed as a result of
    open for write or logged modification information (resulting from
    disconnected operation)

3 The client cache is full (fileobjects),
    this can also happen when no objects can be flushed. This is
    calculated by the client on the assumption of an average filesize of
    16K/file. So a 10MB cache can cache at most 416 fileobjects
    (directories + files + symlinks).... Oh, and there are a couple
    reserved for repair purposes.

4 The partition containing the client cache is full (blocks or inodes),
    Client cache is essentially not yet full, but logfiles
    (/usr/coda/venus.cache/venus.log or /usr/coda/etc/console) or saved
    Coda-state files (/usr/coda/spool/*/*) have filled the partition.

5 There are no more modification log entries available,
    This is uncommon, and more likely to lead to a crashed client.

> What happens ???

Most often #2 or #3, the client-server connectivity was declared weak or
disconnected. The client `transparently' adapted and started logging
modifications, but reintegration of these changes is only allowed with
valid authentication. Furthermore, `tar -xzf' to the cache is a lot
faster than Coda can ship the logged operations across the network. So
even with tokens it is possible to fill a small cache (like your 10MB
one) very very quickly.

Solutions;
    * Make sure you have tokens, ctokens/clog
    * Force the client to not detect `weak' network conditions, cfs strong

    + Maybe venus can be modified to block user applications that try to
      overfill the cache when `connected' but logging, until we shipped
      some changes back to the server.

Jan
Received on 1999-11-19 11:08:31