Hi
This morning i noticed that in one of the servers glusterfsd
daemon was not working, the last log entries were:
patchset: v2.0.4
signal received: 11
configuration details:argp 1
backtrace 1
bdb->cursor->get 1
db.h 1
dlfcn 1
fdatasync 1
libpthread 1
llistxattr 1
setfsid 1
spinlock 1
epoll.h 1
Hi
The
second is 'option transport.socket.nodelay on' in each of your
protocol/client _and_ protocol/server volumes.
where is this option documented ?
--
Thanx & best regards ...
David Saez Padroshttp://www.o
On 09/29/2009 03:39 AM, David Saez Padros wrote:
The
second is 'option transport.socket.nodelay on' in each of your
protocol/client _and_ protocol/server volumes.
where is this option documented ?
I'm a little surprised TCP_NODELAY isn't set by default? I set it on all
servers I write as a m
On Mon, Sep 28, 2009 at 3:49 PM, Corentin Chary
wrote:
> Hi,
> I'm trying to use glusterfs with afr.
> My setup have 2 servers and 2 clients. / is mounted with user_xattr.
> It seems that if you shutdown a server, remove a directory with one or
> more childs, then restart the server, the changes w
Mark Mielke wrote:
I'm a little surprised TCP_NODELAY isn't set by default? I set it on
all servers I write as a matter of principle.
Serious servers intended to perform well should be able to easily beat
the Nagle algorithm. writev(), sendmsg(), or even write(buffer) where
the buffer is buil
David Saez Padros wrote:
Hi
The
second is 'option transport.socket.nodelay on' in each of your
protocol/client _and_ protocol/server volumes.
where is this option documented ?
Thanks for pointing this out.
We wanted to expose this as a regular option in the upcoming 2.1 release
and had in
David Saez Padros wrote:
patchset: v2.0.4
signal received: 11
configuration details:argp 1
backtrace 1
bdb->cursor->get 1
db.h 1
dlfcn 1
fdatasync 1
libpthread 1
llistxattr 1
setfsid 1
spinlock 1
epoll.h 1
xattr.h 1
st_atim.tv_nsec 1
package-string: glusterfs 2.0.4
/lib/libc.so.6[0x7ff43f926db0]
Hi
here you have it:
Core was generated by `/usr/sbin/glusterfsd -p /var/run/glusterfsd.pid
-f /etc/glusterfs/glusterfsd.vo'.
Program terminated with signal 11, Segmentation fault.
#0 0x7f7b568f30a8 in unify_open () from
/usr/lib/glusterfs/2.0.4/xlator/cluster/unify.so
(gdb) backtrace
#
Hello all,
Trying to get Gluster going on a CentOS 5.2 (32bit) machine. The daemon
loads OK, but when the client tries, it spits this out in the log :
+--+
[2009-09-29 11:02:57] E [xlator.c:736:xlator_init_rec] xlator
-Original Message-
From: gluster-users-boun...@gluster.org
[mailto:gluster-users-boun...@gluster.org] On Behalf Of
gluster-users-requ...@gluster.org
Sent: Tuesday, September 29, 2009 7:53 AM
To: gluster-users@gluster.org
Subject: Gluster-users Digest, Vol 17, Issue 47
Send Gluster-u
Daniel Maher wrote:
Hello all,
Trying to get Gluster going on a CentOS 5.2 (32bit) machine. The daemon
loads OK, but when the client tries, it spits this out in the log :
+--+
[2009-09-29 11:02:57] E [xlator.c:736:
I think TCP_NODELAY is critical to performance. Actuall after spending
a large number of unfruitful hours on glusterfs, I wrote my own simple
shared storage with BerkeleyDB backend, and I found that enabling
TCP_NODELAY on my system gives me nearly 10x readback throughput.
Thanks for pointing
Has the gluster-devel list been taken down? I've been trying to send
messages to it for a while but always get them bounced back as
undeliverable.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://gluster.org/cgi-bin/mailman/listinfo/glus
Will Rouesnel wrote:
Has the gluster-devel list been taken down? I've been trying to send
messages to it for a while but always get them bounced back as
undeliverable.
gluster-devel is up and running. I even sent a test mail there for
confirmation and it reached the list :)
Thanks,
Vijay
Hi
I've been noticing some long delays on doing a simple `ls' in
directories that haven't been recently accessed on a test glusterfs
system we've put together. The system(s) consists of a 4 node
DHT + AFR (x1) setup, running 2.0.6 all with 10GbE connectivity
between the nodes (and no there is
On 09/29/2009 07:14 PM, mki-gluste...@mozone.net wrote:
Hi
I've been noticing some long delays on doing a simple `ls' in
directories that haven't been recently accessed on a test glusterfs
system we've put together. The system(s) consists of a 4 node
DHT + AFR (x1) setup, running 2.0.6 all with
16 matches
Mail list logo