On Thu Jan 23 07:41:09 2014, Joe Topjian wrote: > 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.
Could you share a little bit more about your use case or testing please? I'm currently re-implementing cloudfuse and I'm surprised by your comments around the use of temporary files are you working with a local (not over the internet) object store? _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack