<div dir="ltr">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.<div>
<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"> > Also have you looked the gluster-swift project to see what they are doing?<br>
<br>
</div>I have not.  I wasn't aware that they included a client or fusedriver<br>
like this.  I'll look into it.<br></blockquote><div><br></div><div>For reference, gluster-swift can be read about here:</div><div><br></div><div><a href="https://github.com/gluster/gluster-swift/blob/havana/doc/markdown/quick_start_guide.md">https://github.com/gluster/gluster-swift/blob/havana/doc/markdown/quick_start_guide.md</a></div>
<div><br></div><div>It allows Swift to use GlusterFS as a backing store. Swift is still accessed via HTTP, which is the opposite cloudfuse's goal.  </div></div></div></div>