[tahoe-dev] fuse and tahoe

[Greg Troxel]

  [freedombox post about fuse and tahoe]

I read your post, and I think you make good points about why tahoe-like
filesystems are not suitable for being hooked up via FUSE and used for
arbitrary workloads.  But, that blurs two things, and isn't a good
argument that FUSE interfaces aren't the right thing.

A distributed filesystem accessed via FUSE can be efficient or not
depending on whether the requested operations can be implemented
efficiently given how the filesystem works (and of course also depending
on whether the translator layer is actually efficient).
For the backup use case, in addition to "tahoe backup", one can
contemplate rsync, or bup, or various other mechanisms.  It's an
interesting question to see how each works, and if it's slow why.

For me, the real problem with other-than-vfs-integration is that the
distributed filesystem becomes special case and second class, where you
have to run special programs to interact with it.  It may be that there
are a class of very distributed filesystems that are efficient at a
reasonable subset of operations, and that this will cause a number of
useful programs to stay within that subset.  But, the vfs interface is
still a powerful abstraction that allows interoperability.

An interesting exercise would be to take something like coda and turn it
into a stackable layer, separating write caching and conflict resolution
From backend storage.

Not really related, but it seems tahoe on a LAN is far slower than
glusterfs, and I wonder how much of that is fundamental and how much is
an artifact of the implementation.

(I know, work on the code and stop whining...)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20120124/e60daac8/attachment.pgp>