Ok, I tried the debug once before, must have missed it. I did see dome errors on the client side, but not the server side. Here is the log excert: 2007-10-22 00:19:07 D [inode.c:351:__active_inode] fuse/inode: activating inode(16750137), lru=1/1024 2007-10-22 00:19:07 D [fuse-bridge.c:423:fuse_lookup] glusterfs-fuse: LOOKUP 16750137/1193026747.V19Iffa3a9M917884.anubis.mydomain.com (/mydomain.com/webmaster/new/1193026747.V19Iffa3a9M917884.anubis.mydomain.com) 2007-10-22 00:19:07 D [fuse-bridge.c:378:fuse_entry_cbk] glusterfs-fuse: ERR => -1 (2) 2007-10-22 00:19:07 D [inode.c:308:__destroy_inode] fuse/inode: destroy inode(0) [@0x7bbe4a0] 2007-10-22 00:19:07 D [inode.c:381:__passive_inode] fuse/inode: passivating inode(16750137), lru=2/1024 2007-10-22 00:19:07 D [inode.c:351:__active_inode] fuse/inode: activating inode(16753577), lru=1/1024 2007-10-22 00:19:07 D [inode.c:351:__active_inode] fuse/inode: activating inode(16750137), lru=0/1024 2007-10-22 00:19:07 D [fuse-bridge.c:1052:fuse_link] glusterfs-fuse: LINK /mydomain.com/webmaster/tmp/1193026747.P24588.anubis.mydomain.com /mydomain.com/webmaster/new/1193026747.V19Iffa3a9M917884.anubis.mydomain.com 2007-10-22 00:19:07 D [fuse-bridge.c:346:fuse_entry_cbk] glusterfs-fuse: ENTRY => 16753577 2007-10-22 00:19:07 D [inode.c:381:__passive_inode] fuse/inode: passivating inode(16753577), lru=1/1024 2007-10-22 00:19:07 D [fuse-bridge.c:917:fuse_unlink] glusterfs-fuse: UNLINK 16750136/1193026747.P24588.anubis.mydomain.com The client and server run fine without crashing, so I really couldn't backtrace it (or could I?) I tried to find the tla release you mentioned, I am not sure which one to use, do you have a direct link I could use? > Brian Taber wrote: >> I used the patched fuse from the site (fuse-2.7.0-glfs4) and >> glusterfs-1.3.5 I had unify specified because I was planning on adding >> servers soon, I wanted to make sure everything would work fine before >> that. I have already tries with just the posix folder and posix-locks >> and >> no change in the issue. did I grab the wrong fuse? >> > > No, that's the correct fuse (unless there's a newer one, but it's > probably the the problem in any case). > > Have you tried running with the error level set to debug (or with the > regular error level, are you seeing errors in the logs)? You can > specify it with -L DEBUG on both the client and server command lines. > You'll probably see something in there about why it's failed. If you > see a segfault, load up the core (probably in /) in gdb (gdb > /path/toglusterfsd /core.PID) and issue the "bt" command. The glusterfs > team will want that, and they will probably have a fix out within a few > days (if it's a crash), so post it to the mailing list. > > If you haven't already, you might want to try the tla releases. They > seem to be very stable. The download page on gluster.org has info on > how to use tla to get the latest source. > > -- > > -Kevan Benson > -A-1 Networks >
