A group I'm working with recently finished some basic cloudfuse testing and in the end, we weren't 100% comfortable with using it in production. The core reason for this is cloudfuse writing files to /tmp before they get moved to Swift. We played with a few variations of /tmp including using a ramdisk for /tmp, but we were unable to find a way where the IO of /tmp or the limited memory of a ramdisk /tmp would not be a bottleneck for the traffic we were aiming for.
> Also have you looked the gluster-swift project to see what they are > doing? > > I have not. I wasn't aware that they included a client or fusedriver > like this. I'll look into it. > For reference, gluster-swift can be read about here: https://github.com/gluster/gluster-swift/blob/havana/doc/markdown/quick_start_guide.md It allows Swift to use GlusterFS as a backing store. Swift is still accessed via HTTP, which is the opposite cloudfuse's goal.
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
