(Illustration by Gaich Muramatsu)
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 storageReceived on 2011-03-12 20:05:03