Unfortunately, I can't check that issue, as I'm still having an issue
which makes 1.4 completely unusable, lately...
From "cp -a /usr /beast/usr0":
2008-08-06 13:22:53 C [client-protocol.c:223:call_bail] ns0-0: bailing
transport2008-08-06 13:22:53 E
[client-protocol.c:4122:protocol_client_cleanup] ns0-0: forced unwinding
frame type(1) op(34) reply=@0xb233d9f8
2008-08-06 13:22:53 E [client-protocol.c:4122:protocol_client_cleanup]
ns0-0: forced unwinding frame type(2) op(5) reply=@0xb233d9f8
2008-08-06 13:22:53 E [afr.c:3007:afr_close_cbk] ns0: (path=/usr0/bin/free
child=ns0-0) op_ret=-1 op_errno=77(File descriptor in bad state)
2008-08-06 13:22:53 E [socket.c:1193:socket_submit] ns0-0: transport not
connected to submit (priv->connected = 255)
2008-08-06 13:22:53 E [afr.c:3328:afr_stat_cbk] ns0: (child=ns0-0)
op_ret=-1 op_errno=107(Transport endpoint is not connected)
2008-08-06 13:22:53 E [socket.c:712:socket_connect_finish] ns0-0:
connection failed (Connection refused)
2008-08-06 13:23:03 C [client-protocol.c:223:call_bail] ns0-1: bailing
transport2008-08-06 13:23:03 E
[client-protocol.c:4122:protocol_client_cleanup] ns0-1: forced unwinding
frame type(1) op(17) reply=@0xb23408c8
2008-08-06 13:23:03 E [afr.c:3007:afr_close_cbk] ns0: (path=/usr0/bin/free
child=ns0-1) op_ret=-1 op_errno=107(Transport endpoint is not connected)
2008-08-06 13:23:03 E [client-protocol.c:4122:protocol_client_cleanup]
ns0-1: forced unwinding frame type(1) op(0) reply=@0xb23408c8
2008-08-06 13:23:03 E [afr.c:3328:afr_stat_cbk] ns0: (child=ns0-1)
op_ret=-1 op_errno=107(Transport endpoint is not connected)
2008-08-06 13:23:03 E [unify.c:147:unify_buf_cbk] mirrors: child(ns0):
path(/usr0/bin): Transport endpoint is not connected
2008-08-06 13:23:03 E [socket.c:1193:socket_submit] ns0-1: transport not
connected to submit (priv->connected = 0)
Apparently, the ns server doesn't complain.
I've also seen it complain about extended attributes not being support,
even though they are, at least when I tried disabling acl support.
I even tried with btrfs, which lasts longer before freaking out in a
similar manner, although it has an additional issue:
2008-08-06 13:16:06 E [afr.c:4180:afr_readdir_cbk] ns0: (child=ns0-0)
op_ret=-1
op_errno=0(Success)
2008-08-06 13:16:06 E [fuse-bridge.c:1947:fuse_readdir_cbk]
glusterfs-fuse: 7: READDIR => -1 (Success)
2008-08-06 13:16:27 E [afr.c:4180:afr_readdir_cbk] ns0: (child=ns0-0)
op_ret=-1
op_errno=0(Success)
2008-08-06 13:16:27 E [fuse-bridge.c:1947:fuse_readdir_cbk]
glusterfs-fuse: 21079: READDIR => -1 (Success)
2008-08-06 13:16:06 E [posix.c:2974:posix_readdir] ns0: telldir failed:
Success
2008-08-06 13:16:27 E [posix.c:2974:posix_readdir] ns0: telldir failed:
Success
As a result, GlusterFS can't ls/du when on top of btrfs (although I'm
guessing that will be an easy one to fix).
Thanks,
Brent
PS GlusterFS seems very fast on btrfs, at least with metadata-intensive
writes.
On Wed, 6 Aug 2008, Amar S. Tumballi wrote:
Hi Brent,
Vikas fixed some bugs in xattr related path of posix. (in patch-272), can
you check now?
Regards,
Amar
2008/7/30 Brent A Nelson <brent@xxxxxxxxxxxx>
FYI, ls works okay in directories that only contain other directories. If
the directory contains files, it complains. After that, the namespace
glusterfsd processes seem to hang altogether and require a kill -9.
Thanks,
Brent
On Wed, 30 Jul 2008, Brent A Nelson wrote:
On Wed, 30 Jul 2008, Vikas Gorur wrote:
Brent,
Thanks for pin-pointing the patch. I tried to reproduce this with an
AFR+Unify setup. However, I haven't been able to yet. How easy is it to
reproduce this? Which operations did you do before it screwed up?
Right after mounting, I find that df works, but the very first ls -al is
extremely slow, complains, and gives bad results. So it's failing right
away, in my case.
Thanks,
Brent
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
--
Amar Tumballi
Gluster/GlusterFS Hacker
[bulde on #gluster/irc.gnu.org]
http://www.zresearch.com - Commoditizing Super Storage!
