[Gluster-users] dm-glusterfs (was Re: IO performance cut down when VM on Gluster)

[Peter Portante]

----- Original Message -----
> From: "Jeff Darcy" <jdarcy at redhat.com>
> To: gluster-users at gluster.org
> Sent: Monday, January 14, 2013 6:53:58 AM
> Subject: [Gluster-users] dm-glusterfs (was Re: IO performance cut down when VM on Gluster)
> 
> On 1/13/13 11:25 PM, Bharata B Rao wrote:
> > Just wondering if there is a value in doing dm-glusterfs on the
> > lines
> > similar to dm-nfs
> > (https://blogs.oracle.com/OTNGarage/entry/simplify_your_storage_management_with).
> > 
> > I understand GlusterFS due to its stackable translator nature and
> > having to deal with multiple translators at the client end might
> > not
> > easily fit to this model, but may be something to think about ?
> 
> 
> It's an interesting idea.  You're also right that there are some
> issues with
> the stackable translator model and so on.  Porting all of that code
> into the
> kernel would require an almost suicidal suspension of all other
> development
> activity while competitors continue to catch up on manageability or
> add other
> features, so that's not every appealing.  Keeping it all out in user
> space with
> a minimal kernel-interception layer would give us something better
> than FUSE (I
> did something like this in a previous life BTW), but probably not
> enough better
> to be compelling.  A hybrid "fast path, slow path" approach might
> work.  Keep
> all of the code for common-case reads and writes in the kernel, punt
> everything
> else back up to user space with hooks to disable the fast path when
> necessary
> (e.g. during a config change).  OTOH, how would this be better than
> e.g. an
> iSCSI target, which is deployable today with essentially the same
> functionality
> and even greater generality (e.g. to non-Linux platforms)?
> 
> It's good to think about these things.  We could implement ten other
> alternative access mechanisms (Apache/nginx modules anyone?) and

FWIW, I have considered an nginx module ...

> still burn
> fewer resources than we would with "just put it all in the kernel"
> inanity.  I
> tried one of our much-touted alternatives recently and, despite
> having a kernel
> client, they achieved less than 1/3 of our performance on this kind
> of
> workload.  If we want to eliminate sources of overhead we need to
> address more
> than just that one.
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>