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 f0ddba7e0913db505f
> 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 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
langua
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
> 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
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 1d4ef0b891899e3a6dbc8c2087e73cee6f5
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
http://supercolony.gluster.org/mailman/lis
On 8 September 2014 05:05, Krishnan Parthasarathi
wrote:
>
>
> > Bulk of current GlusterD code deals with keeping the configuration of the
> > cluster and the volumes in it consistent and available across the nodes.
> The
> > current algorithm is not scalable (N^2 in no. of nodes) and doesn't
> p
> 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. Som
Hi
Lazy umount is a Linux-only feature that let userland tell the kernel to
umount a filesystem as soon as it drops the last reference to it. It is
used at a few places by GlusterFS and is a portability problem.
brick-replace will not currently work without it, which is a critical
problem.
I wrot
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 wrote:
>> Is there any reason not to consider zookeeper?
>
>
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 over
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 t
Sorry I am not done with backporting yet. I'll able to send the patches by EOD
today. Reviews and regression runs might take couple of more days. Sorry about
the delay.
- Original Message -
> From: "Vijay Bellur"
> To: "Kaleb S. KEITHLEY" , "Gluster Devel"
> , "Raghavendra Gowdappa"
>
All,
The following patches are aimed at making debugging
experience glusterd and synctask-based code in our code base
easier.
-synctask: add backtrace per waiting task
http://review.gluster.com/#/c/8622/
While synctask is a handy mechanism to sequence asynchronous
calls without having to wire t
Emmanuel,
IIRC, lazy umount is being used in glusterd to avoid leaving
behind an entry in /etc/mtab, for every internal mount that
failed to unmount for some reason. replace-brick command doesn't
have a requirement that the umount must happen in a lazy manner.
HTH,
KP
- Original Message
On 09/08/2014 10:29 PM, Krishnan Parthasarathi wrote:
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 :-) Should
As per Jeff's comment on getting the component from bugzilla,
this command works:
[rtalur@rastarpad bugs]$ find . -name "*.t" | \grep -o "[0-9]\+" | tr "\n"
" " |xargs -n 1 bugzilla query --outputformat '%{bug_id}: %{component}'
--bug_id
974007: glusterd
1101647: replicate
1112613: glusterd
95787
18 matches
Mail list logo
