gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] priorities


From: Anand Babu Periasamy
Subject: Re: [Gluster-devel] priorities
Date: Wed, 05 Nov 2008 17:52:43 -0800
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)


We have GlusterFS in production on OpenSolaris / X4500 environment. We do not have access to systems running Solaris and our experience with Solaris is also limited. With limited resources, it is hard to support uncommon / proprietary environments. We are also working aggressively on stabilizing 1.4. Please do not feel that you are ignored. We fully
understand the value of community behind GlusterFS.

Is is possible to provide us remote access?

--
Anand Babu Periasamy
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]
GlusterFS [http://www.gluster.org]
The GNU Operating System [http://www.gnu.org]



rhubbell wrote:
Thanks Dan for the synopsis.

I wish I could experience a bug. (^;
I'm unable to even build the software on Solaris 10 Sparc.

I've seen a lot of software in production environments but when
a product has issues just compiling we usually don't put it on
our short-list of potential solutions.

I had some hope when I first found gluster and saw there was
activity.  But it seems with the commercial leaning of the product
that priorities are shifting. I've seen it in lots of other projects. Just an observation, not making a morality or ethic
call.


On Wed, 2008-11-05 at 11:43 -0800, Dan Parsons wrote:
I'm not really the best person to answer this question but I'll try anyway.

There is a commercial entity behind glusterfs - ZResearch(.com) of which most/all of the developers are employed by. The developers are (imo) very good and quick to respond to nearly every problem, it's just this one particular issue where a response/fix has been a bit slow.

glusterfs is moving from 1.3.x to 1.4.x with some fundamental changes involved but I don't think it's the same as what you mean by "transitional state".

The product has been extremely stable for me (8gbit/s IO spread across 4 servers to 33 cpu nodes, bioinformatics work) and this memory "bug" hasn't caused a crash under real work yet, just testing, but only because our job input size is currently small.

So in summary, I love glusterfs, the devs/company behind it are solid, it performs better for my work than others (pvfs, lustre) - it's just this one io-cache memory bug that's been getting less-than-average attention, and perhaps with this recent spark in attention that will change :)


Dan Parsons


On Nov 5, 2008, at 11:20 AM, rhubbell wrote:

On Wed, 2008-11-05 at 19:55 +0100, Lukas Hejtmanek wrote:
On Wed, Nov 05, 2008 at 10:08:24AM -0800, Dan Parsons wrote:
Lukas, just to confirm your findings, I have the exact same problem and
reported it about 2 months ago. Just like you, when all my stuff was
running under 32-bit, it wasn't an issue because of the 2GB limit, but
now that I'm using 64-bit for everything, it is a potential system
crashing bug.
Yes, it's the same, unfortunately, I have no response from the authors. So
nobody cares?

Well somebody cares.  Us.  But I am new here and wondering how
development on this project is funded. Is it all volunteer?
Partially funded via commercial offerings?

Is the project in a transitional state? Soon to go commercial?



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



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



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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]