[Gluster-devel] Performance Translators' Stability and Usefulness
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.
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.
> 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.
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
More information about the Gluster-devel