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.
--- Begin Message ---#935: zandr's FUSE/NAS idea -------------------------------+-------------------------------------------- Reporter: warner | Owner: Type: enhancement | Status: new Priority: major | Milestone: eventually Component: code-frontend | Version: 1.5.0 Resolution: | Keywords: fuse smb sftp sshfs webdav cache preservation gsoc Launchpad Bug: | -------------------------------+-------------------------------------------- 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. -- Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/935#comment:8> tahoe-lafs <http://tahoe-lafs.org> secure decentralized storage
--- End Message ---
pgpYA0LTKvQYA.pgp
Description: PGP signature
