From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: srfs - a new file system. Date: Wed, 22 Oct 2003 10:22:13 -0400 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20031022142213.GA5037@delft.aura.cs.cmu.edu> References: <20031022045708.GA5636@codepoet.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from DELFT.AURA.CS.CMU.EDU ([128.2.206.88]:24809 "EHLO delft.aura.cs.cmu.edu") by vger.kernel.org with ESMTP id S263420AbTJVOWR (ORCPT ); Wed, 22 Oct 2003 10:22:17 -0400 To: Nir Tzachar Content-Disposition: inline In-Reply-To: List-Id: linux-fsdevel.vger.kernel.org On Wed, Oct 22, 2003 at 12:16:02PM +0200, Nir Tzachar wrote: > if you wish to talk in coda terms, you can say all servers operated > disconnectedly, and then were connected at the same time. the conflict > resolving mechanism we use, is by majority. That's annoying when >50% of your servers were unavailable for a period of time, because all recent changes will be lost when connectivity is restored. > We differ from coda in the sense we don't have a main server, which pushes > Volumes to sub-servers (im not sure what the coda terminology is... ), and Where in the world did you get the idea that Coda has a main server that pushes out modifications? That is so wrong, I don't even know where to begin. > data is served in a load-balanced way. In Srfs, all the data resides on > all servers (hosts) and is replicated between them. > replication takes place at two levels: tree view (plus meta data) and the > actual data. > tree view - the tree view on all hosts is the same. an `ls` on a dir > on any host will produce the same output. > data - data will be replicated to all hosts upon a successful write, > and upon each access to a dirty file on each host. Coda also uses a global namespace that's pretty normal for distributed filesystems (AFS/DFS). So the only differences really are that Coda uses a version-vector based mechanism to detect and resolve version conflicts instead of majority voting. i.e. even when only a single server is accessible for a period of time, the committed updates will eventually propagate to others. And we don't throw away a file just because 2 out of three servers happen to have an old copy and vote against it. And Coda gives an administrator the ability to use different replication groups within his servers for different types of data based on for instance expected access patterns. Temporary objects or files that are rarely used could only have a single replica. Mail folders would have 2 replicas (as only one user would read it, so the replication is only needed to protect against occasional server outage), and data shared by many users (binaries) but rarely updated could be available from many replicas. > all replication is lazy, and happens only on access to dirs / files > (and on successful writes - when the file is being closed.) Did you read _any_ of the Coda papers that were written during the past 16 years? Well, this one is pretty recent and nicely summarizes the history of Coda, and provides an overview of what Coda actually does. M. Satyanarayanan, 'The Evolution of Coda' ACM Transactions on Computer Systems (TOCS) Volume 20, Issue 2 (May 2002) Pages: 85 - 124 http://portal.acm.org/citation.cfm?id=507052.507053&dl=GUIDE&dl=GUIDE&idx=J774&part=periodical&WantType=periodical&title=ACM%20Transactions%20on%20Computer%20Systems%20(TOCS) Jan