As an end user and non-developer, I don't have much to add from the
dev side of things. However all of the discussion in this thread has
prompted me to throw in my 2c.
As a sysadmin running 856TB of GlusterFS in production, I believe the
3.X way of dealing with things (glusterd, dynamic) is far
Great feedback!!
-ab
On Thu, Apr 4, 2013 at 3:50 PM, Daniel Mons daem...@kanuka.com.au wrote:
As an end user and non-developer, I don't have much to add from the
dev side of things. However all of the discussion in this thread has
prompted me to throw in my 2c.
As a sysadmin running 856TB
On 22/03/2013, at 2:09 PM, Jeff Darcy wrote:
snip
The best known example of such a coordination service
is Apache's ZooKeeper[1], but there are others that don't have the
noxious Java dependency - e.g. doozer[2] written in Go, Arakoon[3]
written in OCaml, ConCoord[4] written in Python.
snip
On 03/25/2013 11:59 PM, Anand Babu Periasamy wrote:
gluster meta-volume + zeromq for notification (pub/sub) will solve our
problems largely and still be light weight. In a large scale
deployment, it is not a good idea to declare all the servers as
coordination servers. Since meta-volume is a
On Tue, Mar 26, 2013 at 5:59 AM, Jeff Darcy jda...@redhat.com wrote:
On 03/25/2013 11:59 PM, Anand Babu Periasamy wrote:
gluster meta-volume + zeromq for notification (pub/sub) will solve our
problems largely and still be light weight. In a large scale
deployment, it is not a good idea to
Anand Babu Periasamy abperias...@gmail.com wrote:
On Tue, Mar 26, 2013 at 5:59 AM, Jeff Darcy jda...@redhat.com wrote:
On 03/25/2013 11:59 PM, Anand Babu Periasamy wrote:
gluster meta-volume + zeromq for notification (pub/sub) will solve
our
problems largely and still be light weight. In a
On Tue, Mar 26, 2013 at 8:19 AM, Joe Julian j...@julianfamily.org wrote:
Anand Babu Periasamy abperias...@gmail.com wrote:
On Tue, Mar 26, 2013 at 5:59 AM, Jeff Darcy jda...@redhat.com wrote:
On 03/25/2013 11:59 PM, Anand Babu Periasamy wrote:
gluster meta-volume + zeromq for notification
On 03/26/2013 05:36 PM, Ian Latter wrote:
From a user perspective the cluster establishment is done via text file
configuration to direct nodes to network services;
http://www.xtreemfs.org/quickstart_distr.php
Looks like an alternative worth considering. How does it handle online
Subject: Re: [Gluster-devel] Glusterd: A New Hope
Date: Tue, 26 Mar 2013 17:51:57 -0400
On 03/26/2013 05:36 PM, Ian Latter wrote:
From a user perspective the cluster establishment is done via text file
configuration to direct nodes to network services;
http://www.xtreemfs.org
After reading through this thread, I feel compelled to make some comments.
I'm a user.
On Fri, Mar 22, 2013 at 2:09 PM, Jeff Darcy jda...@redhat.com wrote:
During the Bangalore architects' summit a couple of weeks ago, there
was a discussion about making most functions of glusterd into
On 03/25/2013 05:38 AM, Vidar Hokstad wrote:
I see a number of complaints about this as some sort of admission of
failure.
I wouldn't quite characterize it as failure. It does work, after all.
However, glusterd has kind of reached its limits. Moving it forward has
become increasingly
On Mon, Mar 25, 2013 at 1:07 PM, Jeff Darcy jda...@redhat.com wrote:
I'm a little surprised by the positive reactions to the Gluster on
Gluster approach. Even though Kaleb and I considered it for HekaFS,
it's still a bit of a hack. In particular, we'd still have to solve the
problems of
On 03/25/2013 10:53 AM, Vidar Hokstad wrote:
as long as the
chosen option doesn't make day to day troubleshooting and maintenance
much harder...
Completely agree.
For a large deployment I agree you _need_ to
know those kind of things, but for a small one I'd be inclined to just
make every
On 03/25/2013 12:44 PM, Alex Attarian wrote:
Adding more complexity means only making it a nightmare for administrators.
I've said this times and times and I will say it again, your documentation has
always been bad, out of respect I'm not calling it shit. If you had taken your
time and grabbed
On 03/25/2013 02:24 PM, John Mark Walker wrote:
I would also point out that, as the community lead, I would very much
welcome alternative solutions to be played out on gluster.org
I don't think they'll be successful, but what do I know. I just want to
make it clear that alternative solutions
All and all what I'm asking is to find a way to keep the simplicity, not
just maintaining things, but having an overview of things. So when
something breaks no one has to go through multiple services to figure out
where the problem is.
We all know why gluster was such a success, simple and easy to
On Sun, Mar 24, 2013 at 8:57 PM, Justin Clift jcl...@redhat.com wrote:
On 23/03/2013, at 11:58 PM, Anand Babu Periasamy wrote:
snip
(4) Auto-generated volume spec is too limiting. There are other useful
translators, but not even included (but disabled) by default. Volume
spec file does not
On Mon, Mar 25, 2013 at 11:24 AM, John Mark Walker johnm...@redhat.com wrote:
- Original Message -
On 03/25/2013 12:44 PM, Alex Attarian wrote:
If you disagree with the very idea of having glusterd, then *we have
nothing to
talk about*. If you appreciate the infrastructure it
On Mon, Mar 25, 2013 at 6:07 AM, Jeff Darcy jda...@redhat.com wrote:
On 03/25/2013 05:38 AM, Vidar Hokstad wrote:
I see a number of complaints about this as some sort of admission of
failure.
I wouldn't quite characterize it as failure. It does work, after all.
However, glusterd has kind of
On Sun, Mar 24, 2013 at 9:04 PM, Justin Clift jcl...@redhat.com wrote:
On 24/03/2013, at 8:55 AM, Stephan von Krawczynski wrote:
snip
... the most
important question: the performance tuning. We all know that glusterfs can be
unbelievably slow if you tuned the wrong switches. And really,
On Sat, 23 Mar 2013 18:44:06 -0400
Jeff Darcy jda...@redhat.com wrote:
The trend is for distributed systems to become more autonomous, not less so.
Well, the M*soft trend once was to tell people that their servers can be
administered by the secretary. I guess you can imagine yourself how
On 03/24/2013 01:43 AM, Stephan von Krawczynski wrote:
Read the list ... almost nobody ever complained about that. Instead the list is
full of people
searching for the best (i.e. optimized) _content_ of the volfiles for their
respective setup. So the automated distribution of the vol-files
On 03/24/2013 07:03 PM, Jeff Darcy wrote:
On 03/24/2013 04:43 AM, Stephan von Krawczynski wrote:
So the automated distribution of the vol-files does not help
the majority at all.
It's not just about distribution of volfiles. It's also about ensuring
their consistency across many servers and
On Sun, 24 Mar 2013 19:03:07 -0400
Jeff Darcy jda...@redhat.com wrote:
On 03/24/2013 04:43 AM, Stephan von Krawczynski wrote:
So the automated distribution of the vol-files does not help
the majority at all.
It's not just about distribution of volfiles. It's also about ensuring
their
On 03/24/2013 08:17 PM, Stephan von Krawczynski wrote:
I have the strong impression you are pressed to release something in a
timeline and for reasons currently untold.
What is the reason for this rush of features and increasing instability, nfs
with server-based replication and so on. All
On 23/03/2013, at 11:58 PM, Anand Babu Periasamy wrote:
snip
(4) Auto-generated volume spec is too limiting. There are other useful
translators, but not even included (but disabled) by default. Volume
spec file does not list all possible volume options (but commented)
with default values and
On 24/03/2013, at 8:55 AM, Stephan von Krawczynski wrote:
snip
... the most
important question: the performance tuning. We all know that glusterfs can be
unbelievably slow if you tuned the wrong switches. And really, finding the
right ones is very hard, even for very experienced
On 03/22/2013 06:08 PM, Stephan von Krawczynski wrote:
Why is it you cannot accept that it should be a _filesystem_, and nothing
else?
It would have been a lot better to care about stability, keep it simple and
feel fine. Concentrate on the strength (client based replication setups) and
On Fri, Mar 22, 2013 at 3:08 PM, Stephan von Krawczynski
sk...@ithnet.com wrote:
On Fri, 22 Mar 2013 14:27:45 -0400
Jeff Darcy jda...@redhat.com wrote:
On 03/22/2013 02:20 PM, Anand Avati wrote:e
The point is that it was never a question of performance - it was to
just get basic
During the Bangalore architects' summit a couple of weeks ago, there
was a discussion about making most functions of glusterd into Somebody
Else's Problem. Examples include cluster membership, storage of volume
configuration, and responding to changes in volume configuration. For
those who
On Fri, Mar 22, 2013 at 7:09 AM, Jeff Darcy jda...@redhat.com wrote:
The need for some change here is keenly felt
right now as we struggle to fix all of the race conditions that have
resulted from the hasty addition of synctasks to make up for poor
performance elsewhere in that 44K lines of
On Fri, Mar 22, 2013 at 10:51 AM, Anand Avati anand.av...@gmail.com wrote:
On Fri, Mar 22, 2013 at 7:09 AM, Jeff Darcy jda...@redhat.com wrote:
The need for some change here is keenly felt
right now as we struggle to fix all of the race conditions that have
resulted from the hasty addition
On 03/22/2013 02:20 PM, Anand Avati wrote:e
The point is that it was never a question of performance - it was to
just get basic functionality working.
I stand corrected. Here's the amended statement.
The need for some change here is keenly felt right now as we struggle
to fix all of the race
On Fri, Mar 22, 2013 at 10:09:44AM -0400, Jeff Darcy wrote:
During the Bangalore architects' summit a couple of weeks ago, there
was a discussion about making most functions of glusterd into Somebody
Else's Problem. Examples include cluster membership, storage of volume
configuration, and
On Fri, 22 Mar 2013 14:27:45 -0400
Jeff Darcy jda...@redhat.com wrote:
On 03/22/2013 02:20 PM, Anand Avati wrote:e
The point is that it was never a question of performance - it was to
just get basic functionality working.
I stand corrected. Here's the amended statement.
The need for
35 matches
Mail list logo
