hi guys, we're using 3.1.3 and i'm not moving off it. i totally agree with stephans comments: the gluster devs *need* to concentrate on stability before adding any new features. it seems gluster dev is sales driven - not tech focused. we need less new buzz words - and more solid foundations. gluster is a great idea - but is in danger of falling short and failing if the current trajectory is now altered. greater posix compatibility (permissions, NLM locking) should be a perquisite for an NFS server. hell, the documentation is terrible; it's hard for us users to contribute to the community when we are groping around in the dark too. question : is anyone using 3.2 in a real world production situation? regards to all, -paul On 18 May 2011 14:54, Whit Blauvelt <whit.gluster at transpect.com> wrote: > From reading this list, I wonder if this would be an accurate summary of > the > current state of Gluster: > > 3.1.3 - most dependable current version > > 3.1.4 - gained a few bugs > > 3.2.0 - not stable > > So 3.1.3 would be suitable for production systems, as long as the known bug > in mishandling Posix group permissions is worked around (by loosening > permissions). > > There has been a suggestion that stat-prefetch be turned off, and perhaps > that other, non-default options are better not used. > > Now, I'm not personally knowledgeable on any of this aside from the Posix > group problem. Just asking for confirmation or not of the basic sense I'm > getting from those with extensive experience that 3.1.3 is essentially > dependable, while 3.1.4 is problematic, and 3.2.0 should perhaps only be > used if you want to gain familiarity with the new geo-replication feature, > but avoided for current production use. > > Whit > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20110518/eff9b614/attachment.htm>
