[Apologies up front for questionable posting etiquettes]
Two characteristics of a language (tool chain) are important to me, especially
when you spend a good part of your time debugging failures/bugs.
- Analysing core files.
- Ability to reason about space consumption. This becomes important in
Hi,
At last week's community meeting it was stated that we would release
3.4.6beta1 early this week.
The following fixes have been committed to the release-3.4 branch for
3.4.6 to date:
BUG: 1123289, commit 1d4ef0b891899e3a6dbc8c2087e73cee6f5a7fbe
BUG: 1119894, commit
Two characteristics of a language (tool chain) are important to me,
especially
when you spend a good part of your time debugging failures/bugs.
- Analysing core files.
- Ability to reason about space consumption. This becomes important in
the case of garbage collected languages.
I
I could see Go used for background type jobs or test harnessing in the
beginning, at the discretion of the developer. The question about garbage
collection is an unknown and a good point. To me, it makes sense to get
experience with Go before using it in the I/O path. Particularly as the
While the proposal for Glusterd-2.0 is doing its rounds in the devel/users
lists, let me find out how the Go toolchain fares in debugging a live
application and a core file, with a dash of go routines and channels for good
effect :-) Shouldn't take long. I will share my experience and lets take
On 09/08/2014 05:33 PM, Kaleb S. KEITHLEY wrote:
Hi,
At last week's community meeting it was stated that we would release
3.4.6beta1 early this week.
The following fixes have been committed to the release-3.4 branch for
3.4.6 to date:
BUG: 1123289, commit
SRC:
http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.4.6beta1.tar.gz
This release is made off jenkins-release-87
-- Gluster Build System
___
Gluster-devel mailing list
Gluster-devel@gluster.org
Is there any reason not to consider zookeeper?
I did bring up that idea a while ago. I'm no Java fan myself, but still
I was surprised by the vehemence of the reactions. To put it politely,
many seemed to consider the dependency on Java unacceptable for both
resource and security reasons.
That's disappointing. I can certainly understand wanting to keep dependencies
small, but that sounds like FUD more than a reasoned argument.
I do not envy your position navigating such waters.
On Sep 8, 2014, at 2:38 PM, Jeff Darcy jda...@redhat.com wrote:
Is there any reason not to consider
Is there any reason not to consider zookeeper? The 3.4 release is
quite stable and due to a large number of users, bugs are fixed and
its quirks are known.
I like the idea of RAFT. The paper is well written and very
compelling. The last time I read it, a number of critical issues were
glossed
Hi Paul Robert Marino and Roman
thank you very much for you advise！
to Paul Robert Marino：
In fact， I use XFS as the underlying filesystem in my test cases。
NOW, According to your advise， I will increse the background self heal count
to test， I will do a feedback after my
11 matches
Mail list logo
