I think I'm hitting a hang in rsync. I'm using rev c0d07c098724ee8c382a498cab991f7d8467d778 in the b3.0.x branch. The command is: rsync -raHx --stats --inplace --no-whole-file --delete /xback2_back1/home_rcr36/20110707-000502/ /mnt/btrfs/home_rcr36/current/ Where both file systems are local. Running strace on the process shows no activity. The hanging process is the rsync with the lowest PID. I attached gdb to the hanging rsync. Here is the back trace: 0x000000000041e5c4 in hash_search (f=4, s=0xcc1ec0, buf=0xcc1ef0, len=2000967340) at match.c:211 211 if (updating_basis_file && s->sums[i].offset < offset (gdb) back #0 0x000000000041e5c4 in hash_search (f=4, s=0xcc1ec0, buf=0xcc1ef0, len=2000967340) at match.c:211 #1 match_sums (f=4, s=0xcc1ec0, buf=0xcc1ef0, len=2000967340) at match.c:369 #2 0x0000000000414491 in send_files (f_in=5, f_out=4) at sender.c:337 #3 0x000000000041cd96 in client_run (f_in=5, f_out=4, pid=15684, argc=1, argv=0xcac240) at main.c:1039 #4 0x000000000041d455 in start_client (argc=2, argv=0xcac240) at main.c:1287 #5 main (argc=2, argv=0xcac240) at main.c:1514 The system is Fedora Linux 14 x86-64. I continued the program and reattached the debugger. It was stuck in the same place.
Is it hung? Or just making very slow progress? Is the variable "offset" changing? If not, check if there is a loop in the s->sums[i].chain data. Each value in "chain" gives you a new "i", which should eventually lead to a chain < 0.
I'm sorry - it wasn't a complete hang. It finished 30 mins later when I finally let it finish the file. It was just rather slow processing a 2GB file mostly filled with zeros. I'll close the bug.