On Thu, Nov 14, 2002 at 08:00:23AM -0500, Greg Troxel wrote:
> Hint: it would be really cool if venus/vice would maintain
> rpc packets transmitted
> rpc packets ack failures
> sftp packets transmitted
> sftp packet ack failures
> disconnections
> on a per-peer basis and dump these period
I have had some similar slowdowns, and it seems to have something to
do with the sftp transfers opening up to 8-packet windows. But it
doesn't seem like any packets are being dropped on the wire. I have
not turned on debugging to see the counts of retransmits.
Hint: it would be really cool if ve
On Wed, Jul 03, 2002 at 09:51:34AM -0600, Matthew Excell wrote:
> One of those 7 clients puts a small PostgreSQL database in the coda tree
> - Only one client will ever access it at a time, but it needs to be in
> coda since the machine that accesses it may change. Creating a database
> - somethi
Hi Daniel,
I'm actually in the middle of updating the documentation on Coda as we
speak. Some exciting things are happening with Coda, I want to make sure
that the documentation reflects that. I'm rewritting a complete HOWTO
series for Coda that reflects reality as of version 5.3.18
I'll be g
On Tue, May 23, 2000 at 09:43:31AM -0700, Justin Chapweske wrote:
>
> > NFS/Samba have a completely different model, they are block based. If
> > you read a very large uncached file in Coda, you have to wait until it
> > has been fetched completely.
>
> I take it that this is an implementation
Along these lines, I have a wish-list feature that would be very powerful
and simple to add to the server. A simple command to get the checksum or
cryptographic hash of a file on the server would have a number of useful
applications and wouldn't add much complexity to the server.
About the rsync
> NFS/Samba have a completely different model, they are block based. If
> you read a very large uncached file in Coda, you have to wait until it
> has been fetched completely.
I take it that this is an implementation detail. I'm suprised that since
you guys have the benefit of having a multi-t
[SMTP:[EMAIL PROTECTED]]
Date: mardi 23 mai 2000 16:36
À: [EMAIL PROTECTED]
Objet: Re: performance
On 22 May 2000, at 16:16, Jan Harkes wrote:
> NFS/Samba have a completely different model, they are block based. If
> you read a very large uncached file in Coda, you have to wait until it
On 22 May 2000, at 16:16, Jan Harkes wrote:
> NFS/Samba have a completely different model, they are block based. If
> you read a very large uncached file in Coda, you have to wait until it has
> been fetched completely. Once it is in the cache, read/write access is
> pretty much similar to local
On Mon, May 22, 2000 at 01:19:09PM +0200, tholli wrote:
> Hello
>
> I have been doing some performance checks on Coda comparing it with NFS
> and Samba. My results are good specially I was impresed how fast Coda
> could access the Cashe on the local disk.
>
> It is allthough one thing bothering
[EMAIL PROTECTED] said:
| Write disconnected operation is definitely faster, but still has bugs
| in it.. I've ended up reinitializeing servers twice because of it. ;)
I haven't seen any good server corruption for a while now... and we've
been discussing/working on a change in the kernel-venus p
On Mon, 15 Mar 1999 [EMAIL PROTECTED] wrote:
>
> Many months ago (9/16/1998), Troy Benjegerdes said:
>
> | Untarring linux-2.1.121 on nfs:
> | 4.18user 3.97system 1:14.74elapsed 10%CPU (0avgtext+0avgdata 0maxresident)k
> | 0inputs+0outputs (3163major+9197minor)pagefaults 0swaps
> |
> | Untarrin
Many months ago (9/16/1998), Troy Benjegerdes said:
| Untarring linux-2.1.121 on nfs:
| 4.18user 3.97system 1:14.74elapsed 10%CPU (0avgtext+0avgdata 0maxresident)k
| 0inputs+0outputs (3163major+9197minor)pagefaults 0swaps
|
| Untarring linux-2.1.121 on coda:
| 4.44user 2.84system 1:00:55elapsed
13 matches
Mail list logo
