[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...)
pgp46tfW1ecdq.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
