> -----Original Message-----
> From: Jan Harkes [mailto:jaharkes_at_cs.cmu.edu]
> On Wed, May 16, 2001 at 12:38:41AM +1200, Steve Wray wrote:
> > I just got into coda and now that I'm using LVM
> > its going to make such experiments a lot eaiser.
> > 
> > (this is redhat 7.1, LVM (except root and swap)
> > XFS root et al).
> > 
> > I'm using XFS as the base filesystem on /vicepa
> > Is that ok?
> 
> It doesn't matter what kind of FS is used on the server. Only the client
> is picky because we need to be able to access the container files from
> within the kernel to avoid bouncing all read and write calls up to
> userspace.

I only have 2 linux boxes, both are running RH7.1 with XFS
on LVM. So, one is a client and it has XFS.

I'm not sure how to interpret your comment about the client...?


> > 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]
> > Its like network filesystem performance, only on
> > the server.
> > 
> > What might be wrong?
> 
> 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?

 
> This is aggrevated by the fact that (last time I looked) Linux tends to
> write every dirty buffer to the disk when fsync is called, as there is
> no record of which dirty buffers actually belong to the file we're
> currently fsync'ing.

Does this mean that Linux is particularly bad for Coda?
Is this fixable with any tweaking? Different filesystems?

 
> Peter Braam once measured that, given the existing server semantics and
> kernel support, we could not do better than 100 RVM transactions per
> second. This results in about 100 operations per second when fully
> connected.
> 
> Reintegration is far more efficient, it wraps up to 100 operations into
> one big RVM transaction, so theoretically we would be able to do 10000
> operations per second in write-disconnected mode. In reality there is
> just too much overhead in other areas to even get close to this kind of
> performance.
> 
> Jan
> 
>