From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: srfs - a new file system. Date: Tue, 21 Oct 2003 12:59:28 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20031021165927.GA32402@delft.aura.cs.cmu.edu> References: <1066683638.3f944cf6e6763@horde.sandall.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from [128.2.206.88] ([128.2.206.88]:4066 "EHLO delft.aura.cs.cmu.edu") by vger.kernel.org with ESMTP id S263189AbTJUQ7l (ORCPT ); Tue, 21 Oct 2003 12:59:41 -0400 To: Nir Tzachar Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org On Tue, Oct 21, 2003 at 02:07:04PM +0200, Nir Tzachar wrote: > not at all. > > coda is not self stabilizing at all. > srfs is also a totally distributed file system -> see the doc. In what way do you think that Coda isn't distributed? Also Coda does have 'self-stabilizing' properties, but probably in a different way compared to how you think about self stabilization. When a server becomes loaded (too many clients, heavy CPU/memory usage by other processes, network trouble) it's responses slow down and clients will automatically switch to some lighter loaded replica that stores the same data. We work based on an estimate of the available bandwidth on a per-client basis, and the switch is performed in a non-deterministic fashion, i.e. we don't pick the 'fastest' machine, but decide to switch to a random machine when we're talking to the 'slowest' one. As a result this works very well at balancing the load across all available replicas. This adaptation mostly affects read-oriented data traffic. Similarly, when a client happens to be sending modifications (writes) to an overloaded server, it will at some point switch to writeback caching (write-disconnected operation), in this state it keeps track of modifications without writing them back to the server immediately. During this time it can optimize away some operations (intermediate files created during a compilation) and once the local data has 'aged' enough to be considered stable, it reintegrates the modifications in batches of multiple operations at a time. When several operations arrive in a batch, the server only needs to commit a single transaction for up to 100 operations at a time, which results in a far more efficient use of the CPU and disk IO resources on the server. The trade-off is ofcourse a weaker consistency model. So there is definitely a self-stabilizing mechanism present in Coda. Jan