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

[Stephan von Krawczynski]

On Mon, 14 Jan 2013 06:53:58 -0500
Jeff Darcy <jdarcy at redhat.com> wrote:

> 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 good to think about these things.  We could implement ten other
> alternative access mechanisms (Apache/nginx modules anyone?) and still burn
> fewer resources than we would with "just put it all in the kernel" inanity.

Jeff, sorry, you know that this is not true. You _may_ be right if the
situation was static, meaning all your special implementations would work for
all coming versions of the projects they were built for. But exactly the
continous ongoing development of these projects lets your manpower to maintain
every single implementation explode, sooner or later.
And this is why my suggestion doing only the "special implementation" for the
kernel is really the best choice. You still have to continously maintain it,
but only _one_ and not _ten_ or how many libs, plugins and hacks of other
projects you would like to release.

Yes, you may be right that the kernel implementation may take time. But better
to do it now than in two years when you finally notice that other
projects/competitors are simply not reachable in terms of performance. It is
not glusterfs that is ahead in this area, but others. So you first have to
reach their performance to be a real competitor at all. I can see no hints how
you want to do that with the current implementation. 
Glusterfs is in a proof-of-concept state for about 2 years now. Is there
really much time left to do finetuning of this current state?

-- 
Regards,
Stephan