[Gluster-devel] Performance Translators' Stability and Usefulness

Mickey Mazarick mic at digitaltadpole.com
Mon Jul 6 09:03:26 UTC 2009

I have to start with an admonishment for both Gordon and Geoff. Come on 
guys! A dev thread is not the place to rant at developers, but to look 
for solutions. Please keep the complaining to a minimum and look 
constructively for solutions to the problems. I too have had similar 
pains doing gluster upgrades; but understand that when developing a 
product like gluster there's  a stability vs feature balance that a 
developer must decide on.

That being said do you developers or anyone else in the community have a 
good set of regression tests that you use? 

We've written our own but we're just using bash to create/delete a bunch 
of files but I don't feel it's very adequate. Something from the gluster 
dev team might be more robust especially if it were a binary that 
performed many reads, writes, updates, and deletes to a random set of 
files. It would be great to have some kind of low level tester we could 
run for a few days before going live with new patches.

-Mickey Mazarick

Geoff Kassel wrote:
> Hi Filipe,
>    I think if the GlusterFS devs actually implement the QA process they've 
> (allegedly) had since September last year, that would go a long way to 
> improving stability and reliability across the whole application.
>    If the QA process as described on the Wiki was actually implemented, we 
> would most likely not see two critical data corruption bugs in two 
> consecutive major releases, and functionality like DHT and AFR that has been 
> around for years might have a chance of working as described.
>    As much as I would like to see features like active self-heal and non-stop 
> I/O, perhaps it's time for a GlusterFS feature freeze.
>    During this freeze they could do a proper human-eyeballs-on-code style code 
> review and get their QA processes and testing frameworks developed properly. 
> In doing so, hopefully provide us with the kind of reliability and stability 
> that we should see in a piece of software with the 2.x tag.
>    Heck, maybe they could even submit their project to Coverity for analysis, 
> like I've suggested before. It *is* free for open source projects, and the 
> results come highly regarded.
> Geoff.
> On Mon, 6 Jul 2009, Filipe Maia wrote:
>> I strongly agree with both Gordan and Geoff when it comes to stability.
>> I've been trying to get a simple unify setup (now dht) working to
>> replace my existing nfs file servers and i'm yet to achieve the
>> necessary stability.
>> This kind of feature has long been in GlusterFS and should be stable
>> enough by now, but according to my experience that is not the case.
>> I would urge the GlusterFS developers to focus on stability above all
>> else because that is an absolutely essential quality for a software to
>> be usable, specially one as critical as a file system.
>> Filipe
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel


More information about the Gluster-devel mailing list