Last weekend with 299 a full Zimbra backup completed in 27 minutes. This weekend with 313 the backup was only about 1/2 through after 5 hrs. I aborted the backup and the client crashed. The abort would have tried to remove about 4G of files from the /mnt/glusterfs/backups/tmp folder. The following BT was generated from the core: Core was generated by `[glusterfs] '. Program terminated with signal 11, Segmentation fault. #0 unify_unlink (frame=0xdec4b30, this=0x80585b0, loc=0xddb98dc) at unify.c:2256 2256 list = loc->inode->private; (gdb) bt #0 unify_unlink (frame=0xdec4b30, this=0x80585b0, loc=0xddb98dc) at unify.c:2256 #1 0xb7f32c66 in default_unlink (frame=0xdbc51f8, this=0x80592c0, loc=0xddb98dc) at defaults.c:480 #2 0xb7f32c66 in default_unlink (frame=0xde06ca8, this=0x8059350, loc=0xddb98dc) at defaults.c:480 #3 0x0804ccf3 in fuse_unlink (req=0xdf68980, par=4786914, name=0xcc16770 "BbZslzxnS2Y,8Az0m2v5ExLBXbs=6411-6246.msg1") at fuse-bridge.c:781 #4 0xb7f21461 in fuse_reply_err () from /usr/lib/libfuse.so.2 #5 0xb7f221e3 in fuse_reply_entry () from /usr/lib/libfuse.so.2 #6 0xb7f239c6 in fuse_session_process () from /usr/lib/libfuse.so.2 #7 0x0804abae in fuse_transport_notify (xl=0x8059910, event=2, data=0x8053410) at fuse-bridge.c:1942 #8 0xb7f34cc7 in transport_notify (this=0xddb98dc, event=204699600) at transport.c:152 #9 0xb7f35979 in sys_epoll_iteration (ctx=0xbfb56b14) at epoll.c:54 #10 0xb7f34d9d in poll_iteration (ctx=0xbfb56b14) at transport.c:260 #11 0x0804a29b in main (argc=5, argv=0xbfb56bf4) at glusterfs.c:348
