On Tue, Dec 14, 1999 at 11:54:38AM +0100, Kurt Huwig wrote:
> As I get it right now, I need the space for the Metadata several times:
> 
> 1. Ext2-Metadata for '/vicepa'

This information isn't used by Coda. And it doesn't have ACLs,
versionvectors, volumes etc. Coda servers used to be built on top of an
inode-fs, a special filesystem without associated namespace. In some
places we still have references to functions like iopen(ino_nr).

> 2. Coda-DATA-partition

Together with the RVM LOG this is the `last checkpointed' version of the
meta-data and fileserver state.

> 3. Virtual-Memory containing the DATA-partition

This is the `working copy'. The server makes modification to this area,
when we need to roll back a transaction it can re-fetch it from the
RVM log/data partition. However, the fileservers internally work on a VM
copy of objects stored in RVM and therefore never have to abort any
RVM transaction. It also makes it somewhat less expensive to keep the
state consistent.

> I encountered some inconsistencies with Coda:
> 
> Machine 1 (kurti): Write-disconnected, 10MB venus-cache
> Machine 2 (tanja): Write-connected
> 
> I copied a file with size > cachesize from kurti onto the coda fs.
> 
> ***********************
> kurt_at_kurti:/coda/home/kurt > time cp ~/down/cc32e47.exe .
> 11:45:54 Cache Overflow: (407, -28685)

Yup, well known, the Coda client only knows about the filesize once it
is closed. So the cachesize is a `soft-limit' for local writers. The
nicest thing, ahem, is that once this file leaves the cache, it can not
be fetched back from the servers :)

> kurt_at_kurti:/coda/home/kurt > md5sum cc32e47.exe
> 0ee094d3373b84f25282fcdd191514a1  cc32e47.exe
> kurt_at_kurti:/coda/home/kurt > 11:46:26 Cache Overflow: (407, -29591)
> 11:46:48 Reintegrate: Users:kurt, 2/4 records, result = SUCCESS
> 11:46:56 Cache Overflow: (408, -9797)
> 11:47:05 Reintegrate: Users:kurt, 2/2 records, result = SUCCESS
> 11:47:26 Cache Overflow: (408, -9797)
> 
> ****************************
> kurt_at_tanja:/coda/home/kurt > md5sum cc32e47.exe
> 0ee094d3373b84f25282fcdd191514a1  cc32e47.exe

Here it should have fetched the file.

> kurt_at_tanja:/coda/home/kurt > time md5sum cc32e47.exe
> d41d8cd98f00b204e9800998ecf8427e  cc32e47.exe <-------!!!!!
> 
> real    0m0.434s
> user    0m0.000s
> sys     0m0.000s

Aiii, the open or read must have failed. Why did md5sum not report an
error?

    telos- md5sum /dev/null
    d41d8cd98f00b204e9800998ecf8427e  /dev/null


> kurt_at_tanja:/coda/home/kurt > time md5sum cc32e47.exe
> 0ee094d3373b84f25282fcdd191514a1  cc32e47.exe
> 
> real    0m16.209s
> user    0m1.250s
> sys     0m0.390s

16 seconds to checksum?, the file could have been refetched from the
server here.

> I want to use the coda-machine as a fileserver in a SMB-network. Do you
> plan to have a 'non-caching-very-small-footprint-venus-version', so I
> can do this without the triple cache of files?

No, the consistency model, the kernel module and the client-server
protocol are all based on whole files, not blocks. Coda was not designed
as a block based filesystem.

> Kurt

l8r,
    Jan