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.

> 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.
> 
> Deleting recursively is even worse. I had about 25M
> of files in /coda and ran rm -rf to get rid of them
> (on the machine that is the coda server) and it threw
> up a few errors about permissions... and I left it for
> a while... thought it had crashed.
> Killed it and checked... nope it had gotten about
> half way through.
> 
> 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.

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.

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