[Gluster-users] 2.0.6

[Steve]

-------- Original-Nachricht --------
> Datum: Wed, 19 Aug 2009 00:37:18 +0200
> Von: Stephan von Krawczynski <skraw at ithnet.com>
> An: "Steve" <steeeeeveee at gmx.net>
> CC: gluster-users at gluster.org
> Betreff: Re: [Gluster-users] 2.0.6

> 
> > [lots of flame by Steve]
> > Steve
> 
> Dear Steve,
> 
Lieber Stephan (Ja! Ich kann Deutsch. Bin aus CH.)


> generally you are right. It would possibly be more helpful if I did a lot
> of
> debug work and maybe even code some patches. But the simple truth is, I
> don't
> have the spare time.
>
I do understand that! I am in the same position as you. But don't go from one extreme to the other. No one is asking you to invest hours and hours on debugging. Just a debug log and a stack trace. That's not much to produce and does cost you maybe a bunch of minutes and not hours or days.


> So currently all I can do is to point at every single
> release and post a message whether it is usable in production or not.
>
You have to understand that while this might be your way of handling the situation, it is a very unproductive way in general. It's like expecting some one to make you happy and each time the other is trying to make you happy, you just say: I am still not happy.
The logical step from the person trying to please you is to ask: Why?
And if you can't give the answer then you are making the life of the other very hard. It's is very difficult to look inside you and know why you are not happy. The same is valid when you report: It does not work.
And? What are you expecting? We all noticed that it does not work. And we are willing to make it working. Believe me! Every one of us here would love to see GlusterFS rock solid and fast as light. Everyone! And to get that we all not only expect it to work without issues. No! We don't wait for GlusterFS to magically get bug free. Each of us is contributing in getting it bug free. Bare minimum in that undertaking is to send some more info then just a "works"/"does not work".


> Unfortunately none of the releases are so far. I do think that this is a
> great
> project, and I do think the coders have real problems. Why? Because the
> problems I see are _easily_ reproducable in a very simple test bed they
> should
> actually have their hands on if coding such a project.
>
I don't agree with you. Look! I use Gentoo Linux over here. My system is at the edge regarding some packages. I use GCC 4.4.1, Glibc 2.10.1, etc... I compile my packages with:
-----
CFLAGS="-march=native -O2 -pipe -fweb -frename-registers -ftree-vectorize -floop-interchange -floop-strip-mine -floop-block -ftree-loop-optimize -freorder-blocks-and-partition -fgcse-sm -fgcse-las -maccumulate-outgoing-args -funswitch-loops -ftracer -fprefetch-loop-arrays -fno-ident -fno-strict-overflow -mfpmath=sse -mmmx -msse -msse2"

CXXFLAGS="${CFLAGS} -fno-enforce-eh-specs -ffriend-injection"

LDFLAGS="-Wl,-O1 -Wl,--add-needed -Wl,--as-needed -Wl,--hash-style=both -Wl,--sort-common"
-----

While this might be "normal" for me, it is sure not normal for most users to use those compiler flags and use such a recent GCC ang Glibc. And this is just one part of the whole chain. Now add other components like Linux Kernel, Linux Headers, used file system, used transport mechanism, etc... all this influences how GlusterFS is working. So if I would manage to crash GlusterFS and then go and to the GlusterFS mailinglist and just say: It does not work!

What info is that? It is a info but where is the meat on the bone? There are to many places influencing GlusterFS that it is ultra hard to spot out of the air where the problem could be. So at least some basic info should flow from your site into the direction of the GlusterFS developers to help them finding the problem sooner. I mean: You self are as well interested to get that issue solved. So how much time is it to dump a stack trace and send a debug log? Not much! And can you imagine how much value that has for the developers? Pretty much! If you are crawling day by day in code then soon or later you get "blind" and you overlook issues other would have spotted if they would look with naive eyes at the issue. And now imagine a bunch of developers working on that huge code. They all get "blind". Somehow. And this is where we as a community come into play. We don't only have that naive viewpoint but we all together have a gazillion of different hardware and different setups. Because we often don't know how to do it the right way, we even might combine configuration switches and many other things together a GlusterFS developer would never ever dreamed of. So why not levering that "crazyness" and diversity and each time when having a crash with our GlusterFS quickly take the time to produce the bare minimum to accelerate the problem solving? Or are you really expecting the GlusterFS developers to go from line 1 to the last line (I don't know how many lines of code GlusterFS has) and search for a possible crash? And do that every time some one is reporting an problem? NO WAY! They would never ever get anything done. It's impossible. Sorry. No one is working like that. Your auto mechanic is as well not going to take your whole car into peaces to find problems when you report him an issue with your car. He as well is going to ask you what problem you have, etc... and then he is going to fix it. Luckily the auto mechanic has your car in front of him and can even without your input try to find issues. But the GlusterFS developers don't have your box in front of them and you expect them to find the reason for that crash? HALLO? This might work to a certain extend but it's a ultra waste of time. If I would be in the situation of the GlusterFS developers then I would do some QA (including running bonnie++ for hours) with each release and then release it and then if someone would post to the GlusterFS mailing list saying that it does not work but not sending any debug log or stack traces, then I would IGNORE that message. I would NOT CARE AT ALL! Really. I am brutally honest with you. I would just ignore such messages.

 
> 2.0.6 does not simply core dump, it freezes the box (server side).
>
Just that fact alone should ring all alarm bells in your head and you should say to you self: I owe myself, the GlusterFS developers and particularly all GlusterFS users out there that I take myself the time and report the error including a debug log and if possible a stack trace.
If everyone using GlusterFS would be like you regarding problems report then GlusterFS would be not here where it is today.


> I have not told the crew to code something complex like glusterfs, they
> decided to do it. I think it is only fair to point to the problems even if
> the
> feedback is small, still it is at least some feedback.
>
I did not complained about you sending a feedback. I just complained about the quality of the feedback. It's so low that it does not matter. You could have kept the feedback for yourself. Has from my viewpoint the same effect as posting into the mailing list: "Does not work.... Concentrate on stability and stop adding new features."

You know that in German we have an expression: "Es ist der Ton der die Musik macht." and the way you posted that message is just not optimal.


> I know it can be very annoying to only look after stability issues. But I
> will
> not stop to tell them that, even at the risk of being flamed for it.
>
Then please do it in a professional way. If you can't produce stack traces or send debug logs, then set up a script checking out GlusterFS from GIT every hour or so and run your bonnie++ test script and if the script crashes then automatically send a message from the script here to the mailing list writing what GIT commit the script tested and that it crashed. Like that you save yourself much trouble writing the same again and again and you save yourself more wasted time (since you write that you don't have much time anyway).


> And
> the
> only reason for that is: it is worth it.
> 
Yes! It is worth reporting bugs. That's one of the reasons the mailing list is here. But it's a medium where we can interact with each other. It's not a push channel. So please take my feedback as well and if you can produce some more info in the future when reporting problems then do it. PLEASE! PRETTY PLEASE! I beg you on my knees to do it. Not just for you. For us all here trying to get along with GlusterFS. PLEASE!


> -- 
> Regards,
> Stephan
>
Grüsse aus Zürich

Steve
-- 
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser