Re: Performance Translators' Stability and Usefulness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks!
-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@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel


_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel


--




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux