(Illustration by Gaich Muramatsu)
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, JanReceived on 1999-12-14 12:48:16