Open Stack

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?