Coda File System

what gdt is saying about Coda on the tahoe-lafs list

From: Greg Troxel <>
Date: Sat, 12 Mar 2011 20:04:52 -0500
Coda and tahoe have different goals, but Coda people should know about
tahoe; see www.tahoe-lafsorg.

Briefly, servers store erasure-coded ciphertext, and users have
capabilities that encode the encryption key, erasure coding paramaters,
and a storage index.  There is no locking, and no attempt to provide
semantic consistency approaching traditional unix filesystem behavior.
One renews leases on stored shares and other shares are garbage
collected.  But unlike coda, the storage grid can include people you
don't trust (or even know) and storage nodes can come and go without any
real trouble.

This message is about a discussion in tahoe to make a caching gateway,
so that not every file is fetched every time.

Return-Path: <>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
X-Spam-Status: No, score=-2.9 required=1.0 tests=BAYES_00,MISSING_HEADERS,
	T_RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-DCC: :_DCCR
Received: from ( [])
	by (Postfix) with ESMTP id 8D69952C1
	for <>; Sat, 12 Mar 2011 19:59:40 -0500 (EST)
Received: from (localhost [])
	by (Postfix) with ESMTP id 1FC24352581;
	Sat, 12 Mar 2011 16:59:40 -0800 (PST)
From: "tahoe-lafs" <>
X-Trac-Version: 0.12.1dev-r9947
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.1dev-r9947, by Edgewall Software
X-Trac-Project: tahoe-lafs
Date: Sun, 13 Mar 2011 00:59:40 -0000
Subject: Re: [tahoe-lafs] #935: zandr's FUSE/NAS idea
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 935
In-Reply-To: <>
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 ( []); Sat, 12 Mar 2011 19:59:41 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

#935: zandr's FUSE/NAS idea
     Reporter:  warner         |       Owner:=20=20=20=20=20=20=20=20=20=20=
         Type:  enhancement    |      Status:  new=20=20=20=20=20=20=20=20=
     Priority:  major          |   Milestone:  eventually=20=20=20=20=20=20=
    Component:  code-frontend  |     Version:  1.5.0=20=20=20=20=20=20=20=
   Resolution:                 |    Keywords:  fuse smb sftp sshfs webdav c=
ache preservation gsoc
Launchpad Bug:                 |=20=20

Comment (by gdt):

 There is prior art that should be studied, in particular Coda.  Coda's
 primary concept is that files are stored on replicated servers, and that
 clients have a cache.  In this way it is similar to AFS, which can satisfy
 reads from the cache when no servers are reachable.  Coda adds the ability
 to do disconnected writes, where changes are cached and reintegrated.
 This in turn requires fairly complex conflict detection and resolution

 Not required by the above vision, but also present in Coda, is a kernel
 module (for Linux, and for various BSDs) that implements vnodeops and
 passes operations to userspace.  This is similar to FUSE, but predates it
 - I've been using it since probably 1997.  One of Coda's design goals is
 to be efficient once you have the file - operations on a file in coda are
 actually done on the container file, which is a normal file on the local
 disk, and these operations are short-circuited in the kernel so they are
 almost as fast as local file operations.  On read of a file that doesn't
 have a container file, there is a pause while it's faulted in, and on
 close of a file that was opened for writing a store operation begins.

 Were Coda to start over now, it should use FUSE, and FUSE would be
 extended to have fast container file redirects.   I would then argue that
 the caching FUSE module is generic, and can serve both a Coda backend as
 well as a tahoe back end, or at least could be written so that most code
 is shared.

Ticket URL: <>
tahoe-lafs <>
secure decentralized storage

Received on 2011-03-12 20:05:03