Open Stack

In our case, cloudfuse was used as a proxy to a remote object store.

Users would upload files to the server to a mount point handled by
cloudfuse. So as the file is being uploaded, cloudfuse is storing it in tmp
and then passing it on to Swift. We were able to easily swamp the IO or, if
/tmp was on a ramdisk, overflow tmp.


On Thu, Jan 23, 2014 at 9:58 AM, Clark, Robert Graham
<robert.clark at hp.com>wrote:

> 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140123/1d032607/attachment.html>