Coda File System

RE: ok lets see now...

From: Steve Wray <steve.wray_at_the.net.nz>
Date: Thu, 17 May 2001 11:05:51 +1200
> From: Shafeeq Sinnamohideen [mailto:shafeeq_at_cs.cmu.edu]
> On Wed, 16 May 2001, Steve Wray wrote:
>
> > > It doesn't matter what kind of FS is used on the server. Only
> the client
[snip]
> >
> > I'm not sure how to interpret your comment about the client...?
>
> The client venus cache partition must be on an ext2, reiser, or ramfs
> partition for it to work. This is because when the Coda kernel module gets
> a request, it must be able, in the kernel, to forward it to the file
> system that contains the container file so it can do the operation.

Which is the container? /vicepa?
Is that the cache partition on the client?
I'm still groping around the terminology here...

On the toy client I was working with, all partitions
were LVM/XFS except for those holding rvmlog and rvmdata,
these were seperate logical volumes and were unformatted.


> > > > Also, I'm noticing that when I try to populate the
> > > > /coda filesystem it seems really slow; even on the
> > > > machine thats actually hosting that volume.
> > [snip]
> > > RVM is probably most of the cost. Adding and removing directory
> > > entries (i.e. creating and deleting files) involve a lot of RVM
> > > operations. RVM is dealt with syncronously, i.e. all modifications are
> > > explicitly flushed and committed to disk before we return from an
> > > operation. Also, all RVM transactions are serialized, killing any form
> > > of gain that might come from having multiple concurrent threads.
> >
> > So this is an unavoidable performance problem with Coda in general?
>
> Yes, server replication depends on having strong guarantees about the
> state of a server when it is restarted after a crash. This requires
> file metadata operations to be transactional, which requires the
> synchronous write to a write-ahead log.
>
> The overall design of Coda assumes that writes are much less frequent than
> reads, which is the experience from AFS. Thus Coda is less suited for
> workloads that write heavily.

ohhhhh so you wouldn't want /usr/*/src on it...
:)


> Of course, the server doesn't do anything special for the client running
> on the same machine, only the bulk data transfers go faster across the
> "network".

ok so WRT populating a coda directory, it doesn't really matter if
its done by the server or some client? (performancewise)


> > Does this mean that Linux is particularly bad for Coda?
> > Is this fixable with any tweaking? Different filesystems?
> >
> On the BSDs, one can place the RVM log file on a raw disk partiton, so
> accesses will not go through a file system.

Thats what I did in Linux...

> Generally, placing the log file an a separate physical disk will help,
> since only the log needs to be appended to synchronously, while the data
> file and /vicepa can be written lazily.

It can be hard to arrange that on LVM...
:)
it kinda makes the disks transparent...
Received on 2001-05-16 19:09:40