Coda File System

Re: how is it working on freebsd

From: Fredrik Bodin <fredrik_at_sicanet.com>
Date: Sun, 06 Oct 2002 16:30:46 -0400
Yes, the last time i got terrible performance from the coda filesystem.
Never found out what the problem was. Only notices i can remeber i got, was
somthing about limiting bandwith. Got them in the log files for coda or the
system log.

Wat was abit strange, was that in disconnect mode, it still was slow, and
the client logged the same messages.

Setting up a fresh FreeBSD 4.6.2 box now to do some testing on, and see if i
can get it to work this time, with a little bit more luck.

Cheers!

Fredrik
----- Original Message -----
From: "Jan Harkes" <jaharkes_at_cs.cmu.edu>
To: <codalist_at_TELEMANN.coda.cs.cmu.edu>
Sent: Sunday, October 06, 2002 9:58 PM
Subject: Re: how is it working on freebsd


> On Sun, Oct 06, 2002 at 01:47:09PM +0200, Fredrik Bodin wrote:
> > I was wondering if everybody is running this system on linux, or do we
> > have a few that is running it on FreeBSD.
>
> There are a couple of FreeBSD users, at least 2 that I can name right
> away, probably a couple more when I think a little harder.
>
> > If anyone have some tips'n tricks on setting it up on freebsd, it
> > would be helpful.
>
> Shafeeq, that's your cue ;)
>
> > Tested it one time for a coupel of months ago, but it seemed very slow
> > on performance (probarly i have done something wrong) but it tok ages
> > to write a small file from the coda client to the coda server.
>
> I remember, I'm still unsure why you were seeing that absolutely
> horrible performance. Wasn't it something like 3x slower than expected?
> The CVS version of rpc2 has a patch that avoids ACK duplication which in
> some situations would create parallel data pushes where all the filedata
> is in fact sent 2 or multiple times over the same wire.
>
> On the other hand, because we use whole file caching and write back the
> complete file (only) when the file is closed, we are almost reliably
> slower than other network filesystems. NFS will f.i. allow you access to
> parts of the file pretty quickly because it doesn't care about having a
> consistent local copy. Similarity it will flush dirty blocks back to the
> server long before you actually close the file because it doesn't care
> whether other clients see a consistent copy of the data on the server.
>
> Jan
>
>
Received on 2002-10-06 16:43:01