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