[Gluster-devel] get error while write for stripe

[Anand Avati]

Jack,
 I would really like to see a backtrace of a core. my current guess is
that you have created a stripe volume over two previously existing
storage/posix volumes. and you have tried to write to an existing
file. can you confirm if this is the correct case?
               certain error handling code in stripe is
undergoing some enhancements currently and this is one of the fixes
which will come in the strip commit. 
  all the current cluster/* translators expect you start from a fresh
empty stroage/posix volume. in the 1.4 with self-heal you can start
with any existing directories too and appropriate changes will be made
to the other servers.

avati

On Mon, Apr 30, 2007 at 09:34:04PM +0800, ????????? wrote:
> Dear Avati
> Thank you for your reply message  and  I am sorry for my poor English.
> I use tla to install "glusterfs-1.3.0-pre3" , and use the same
> configures but disable "debug/trace " xlator .
> 
> Here is the client side log below:
> #######################################################################
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:215/gf_print_trace()]
> debug-backtrace:Got signal (11), printing backtrace
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/libglusterfs.so.0(gf_print_trace+0x26)
> [0x9b0e02]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/lib/tls/libc.so.6 [0x77c898]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/libglusterfs.so.0(dict_get+0x11)
> [0x9ac28d]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/glusterfs/1.3.0-pre3/xlator/protocol/client.so
> [0x1159b9]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/glusterfs/1.3.0-pre3/xlator/cluster/stripe.so
> [0x11ab66]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:[glusterfs] [0x804f094]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/lib/libfuse.so.2 [0xa1a06e]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/lib/libfuse.so.2 [0xa1afb4]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/lib/libfuse.so.2(fuse_session_process+0x17)
> [0xa1c2cb]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:[glusterfs] [0x804ae50]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/libglusterfs.so.0(transport_notify+0x13)
> [0x9b1c3f]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/libglusterfs.so.0(sys_epoll_iteration+0xd7)
> [0x9b22b3]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/usr/local/glusterfs-hacker/lib/libglusterfs.so.0(poll_iteration+0x1b)
> [0x9b1dd7]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:[glusterfs] [0x804a6e3]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:/lib/tls/libc.so.6(__libc_start_main+0xd3) [0x769de3]
> [Apr 30 21:26:24] [CRITICAL/common-utils.c:217/gf_print_trace()]
> debug-backtrace:[glusterfs] [0x8049fd1]
> 
> #######################################################################
> 
> 
> Jack Hsu
> 
> 2007/4/30, Anand Avati <avati at zresearch.com>:
> >
> >Jack,
> > can you use the latest TLA and give the log from the client side as
> >well as a backtrace of the core dump (if any) ?
> >
> >regards,
> >avati
> 

-- 
ultimate_answer_t
deep_thought (void)
{ 
  sleep (years2secs (7500000)); 
  return 42;
}