Happens in 3.9, but only on some filesystems. Those filesystems happen to have extended inode refs enabled.
Are the files that are missing happen to be ones with extended irefs? I will try and reproduce locally.
I got one report from someone who didn't have extended inode refs enabled (https://github.com/g2p/bedup/issues/20#issuecomment-17476323), I've asked him to subscribe to this bug. Most files are actually missing, on my filesystem there's a random mozilla checkout that contributes 13215 results, the rest (about 500) are random files from my home. I haven't been able to reproduce with a clean filesystem. I'll try to send debug-tree output but it seems like it's going to be very large.
Instead of debug-tree can you do btrfs-image? Pull from my git tree and use the btrfs-image in there git://github.com/josefbacik/btrfs-progs.git and then give me the steps you use to reproduce and tell me what I'm looking for so I can make sure I see exactly what you are seeing.
It failed to dump: sudo ./btrfs-image -s -c6 /dev/mapper/blah blah.btrfs-image checksum verify failed on 65536 found DA97CF61 wanted 6B checksum verify failed on 65536 found DA97CF61 wanted 6B Csum didn't match Error reading metadata block Error adding block -5 checksum verify failed on 65536 found DA97CF61 wanted 6B checksum verify failed on 65536 found DA97CF61 wanted 6B Csum didn't match Error reading metadata block Error flushing pending -5
Oh, I'll umount first.
Same error after unmounting.
Please apply this patch to progs, fixes the checksum bug: https://patchwork.kernel.org/patch/2526141/
Yup, turns out I didn't need to upload the image after all (it was a bit shy of 3GB). I posted a fix for the search ioctl here: http://comments.gmane.org/gmane.comp.file-systems.btrfs/25550
Applied to btrfs-next, closing. Thanks!