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: <trac_at_tahoe-lafs.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on fnord.ir.bbn.com
X-Spam-Level: 
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
X-Original-To: gdt_at_ir.bbn.com
Delivered-To: gdt_at_ir.bbn.com
Received: from tahoe-lafs.org (tahoe-lafs.org [75.101.14.39])
	by fnord.ir.bbn.com (Postfix) with ESMTP id 8D69952C1
	for <gdt_at_ir.bbn.com>; Sat, 12 Mar 2011 19:59:40 -0500 (EST)
Received: from tahoe-lafs.org (localhost [127.0.0.1])
	by tahoe-lafs.org (Postfix) with ESMTP id 1FC24352581;
	Sat, 12 Mar 2011 16:59:40 -0800 (PST)
From: "tahoe-lafs" <trac_at_tahoe-lafs.org>
X-Trac-Version: 0.12.1dev-r9947
Precedence: bulk
Cc: tahoe-lafs-trac-stream_at_tahoe-lafs.org
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
Reply-To: tahoe-dev_at_tahoe-lafs.org
X-URL: http://tahoe-lafs.org
Subject: Re: [tahoe-lafs] #935: zandr's FUSE/NAS idea
X-Trac-Ticket-URL: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/935#comment:8
Message-ID: <054.0491f799f2faf34d893f65f2bc03edc9_at_tahoe-lafs.org>
References: <039.ac9e145e26a029786164b8d1c2f6ee6d_at_tahoe-lafs.org>
X-Trac-Ticket-ID: 935
In-Reply-To: <039.ac9e145e26a029786164b8d1c2f6ee6d_at_tahoe-lafs.org>
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (fnord.ir.bbn.com [0.0.0.0]); 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
=2D------------------------------+-----------------------------------------=
---
     Reporter:  warner         |       Owner:=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
         Type:  enhancement    |      Status:  new=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20
     Priority:  major          |   Milestone:  eventually=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20
    Component:  code-frontend  |     Version:  1.5.0=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20
   Resolution:                 |    Keywords:  fuse smb sftp sshfs webdav c=
ache preservation gsoc
Launchpad Bug:                 |=20=20
=2D------------------------------+-----------------------------------------=
---

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
 code.

 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.

=2D-=20
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/935#comment:8>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage