begin  Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:
> On Thu, Dec 25, 2003 at 06:45:06PM +0000, Joerg Sommer wrote:
>> firstly, I wish all a merry christmas.
>
> And a Happy New Year :)

>From me too.

> The numbers are right, but I do not necessarily agree with all the
> premises or conclusions. First of all, we're clearly not competing with
> local disk filesystems. Those do not have to deal with replication,
> centralized storage, and some do have lower consistency constraints.

ACK.

> But it is nice to know where the 'theoretical limits' of performance
> are, I don't expect to ever be faster than the underlying filesystem we
> use for our cached data. Most of these tests were on 2.0 (or early 2.2)
> kernels. One of the main culprits for the bottleneck, the context
> switch, has improved tremendously over time.

That's good to hear.

> device/inode numbers down. Now we can hand the still open file
> descriptor and in most cases the we can be reading the still in-memory
> data before the bits have actually hit the disk.

Do you plan to take advantage of ACLs of the cache filesystem?

> other hand my client cache is probably about 10x larger as well which is
> slowing down my client significantly because it has more objects to
> manage and there are still codepaths that are O(n^2),

ouch. :)

One point of the intermezzo idea, I find really great, is the separation
between kernelspace and userspace. If I understand right, the coda module
asks the userspace daemon (venus) where a file is in the cache and the
coda daemon makes a lookup and reports to location. So coda demands a
running userspace daemon (venus). But if it does lookups itself, it would
be possible to use a disk cache for a readonly coda. So it would be
possible to restart the venus daemon without interrupting processes
accessing files readonly in the codafs.

What's the reason for this? Currently, we're running a computer pool with
diskless clients based on AFS. But AFS has the know disatvantages and we
plan to switch to coda. One problem with AFS is, it isn't possible to
restart the userspace daemon, which leads to the problem we use everytime
the binary from the initrd. (redundancy) If kernelspace could live
without a daemon in userspace we could run venus from an initrd, fetch
the newest version of venus and other necessary files from the server and
restart the daemon fetched from the server, to gain write access again
and do all the other things.

Joerg.
end.
-- 
                                   Jens Dittmar in de.comp.security