Re: [Gluster-devel] Performance Translators' Stability and Usefulness

[Gordan Bobic]

Geoff Kassel wrote:

> > > Finally - which translators are deemed stable (no know issues -
> > > memory leaks/bloat, crashes, corruption, etc.)?
>>
> > We can definitely vouch for a higher degree of stability of the
> > releases. Otherwise, I dont think there is any performance translator we
> > can call completely stable/mature because of the roadmap we have for
> > constantly upgrading algorithms, functionality, etc.
>
> When will the Gluster team be able to deliver a stable, mature, and reliable 
> version of GlusterFS?

While I can relate to that sentiment to some extent, I think you're a 
bit overly harsh. Stability has, in my experience, improved quite a lot 
recently.

> I have been using GlusterFS since the v1.3.x days, and I have yet to see a 
> version since then that doesn't crash at least once a day from just load on 
> even the simplest configurations.

I wouldn't say daily, but occasionally, I have seen lock-ups recently 
during multiple glusterfs resyncs (separate volumes) on the new/target 
machine. I have only seen it once, however, forcefully killing the 
processes fixed it and it didn't re-occur. I have a suspicion that this 
was related to the mounting order. I have seen weirdness happen when 
changing the server order cluster-wide, and when servers rejoin the cluster.

> Then there's the data corruption bug of the early 2.0.0 releases, which has 
> kept me (and no doubt others) from upgrading to these releases.

Yes, that was bad, 2.0.2 is pretty good. Sure, there is still that 
annoying settle-time bug that consistently fails the first attempt to 
access the file system immediately after mounting (the time gap is 
pretty tight, but if you script it, it is 100% reproducible). But other 
than that I'm finding that all the other issues I had with it have been 
resolved.

> I have read about the Gluster QA team, but quite frankly, I have yet to see 
> the fruits of this team's work. Letting through a bug of that magnitude in a 
> major release blew a lot of trust I had in the Gluster team's QA process.
>
> When will regression tests be used? It's been months now since this bug, and 
> still I don't see any sign of the use of this simple, industry-standard 
> technique to minimise the risk of such issues slipping through again.

What exactly do you mean by "regression test"? Regression testing means 
putting in a test case to check for all the bugs that were previously 
discovered and fixed to make sure a further change doesn't re-introduce 
the bug. I haven't seen the test suite, so have no reason to doubt that 
there is regression testing being carried out for each release. Perhaps 
the developers can clarify the situation on the testing?

Personally, I think of much benefit to testing would be having syslog 
support so that when using glusterfs as the root file system the logs 
can be acquired/redirected for troubleshooting. This is currently not 
possible since at the point where glusterfs starts up there is no 
permanent root file system that logs can be written to.

Gordan