CloudFS vs. ecryptfs vs. encfs vs. Tahoe-LAFS

Jeff Darcy jdarcy at redhat.com
Fri Jun 10 17:29:29 UTC 2011


> Also, because I was only using one "brick"
> this test didn't take advantage of the multi-threading I've added to the
> GlusterFS transport layer.  I should re-do that test with three or so
> bricks (even though they're using the same server volume) and see if it
> makes a difference.

It sure did.  I should have done it this way before, since the problem
of adding crypto code to the single-threaded Gluster polling loop was
already known and addressed.  New table:

(MB/s)        write    rewrite    read
CloudFS        24.9       31.3    86.1
ecryptfs        5.1       18.2    89.9
encfs           2.3        2.3    81.2
Tahoe-LAFS      3.2        3.5     4.7

That's not a bad picture.  Some day I'd like to get similar numbers on
the faster machines, with more than one server and ideally more than one
client as well (which should make CloudFS and Tahoe-LAFS both look
better relative to ecryptfs and encfs).


More information about the cloudfs-devel mailing list