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

[Jeff Darcy]

On 01/14/2013 07:27 AM, Stephan von Krawczynski wrote:
> 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.

Absolutely incorrect, because there's this little thing called 
modularity to consider.  Since translators are modular, very few changes 
to their higher-level functionality would require porting to a specific 
environment where all of the necessary libraries etc. are still 
available.  By contrast, even a single port to the kernel where that's 
not the case would require a great deal of effort.

> And this is why my suggestion doing only the "special implementation" for the
> kernel is really the best choice.

Untrue again.  Even with a kernel implementation, the transitions 
through the VFS layer impact performance compared to having the code 
directly in the app (as Joe has pointed out) or emulator (as Bharata has 
done).

> Yes, you may be right that the kernel implementation may take time.

You have no idea.  No, really, no clue at all.  I've actually 
implemented distributed filesystems in the kernel, and ported other 
complex bits of code (e.g. a distributed lock manager) there as well.  I 
know precisely how much work is involved, and how much the extra 
challenges of developing kernel code slow that work down.  In our case 
there's also an issue of finding or implementing alternatives for things 
we get "for free" in user space, so we'd be porting more than our own 
code.  The retraining plus the work involved plus the extra testing plus 
the licensing issues all make the whole thing a non-starter.  It's easy 
for people who never produce anything to say otherwise, but being easy 
to say doesn't make it true.

> to do it now than in two years when you finally notice that other
> projects/competitors are simply not reachable in terms of performance.

Incorrect yet again.  I recently tested vs. one of our highly touted 
competitors, on the same hardware.  Despite having a kernel client, they 
only achieved *one third* of our performance on a synchronous write test 
(which is pretty close to the type of I/O a virtual machine would do). 
Why?  Because they'd replaced one kind of overhead with several others. 
  Putting code in the kernel is an optimization, optimizations aren't as 
valuable as algorithmic improvements, and algorithmic improvements are 
easier to make without following your stupid advice.  Please stop 
wasting everyone's time repeating claims that have already been refuted 
over and over again.  This list is not a substitute for therapy.