On 2014-03-08 18:40, Travis Cross wrote: > Mar 8 18:13:23 kernel: [ 2041.956270] btrfs: btrfs_compare_tree detected a change in one of the trees while iterating. This is probably a bug. xaba on IRC helpfully encouraged me to run btrfs check on the device. I receive a flood of messages: Extent back ref already exists for <x> parent 0 root <y> Then it pauses for awhile, and starts flooding out: ref mismatch on [<x> 4096] extent item 1, found 2 Incorrect global backref count on <x> found 1 wanted 2 backpointer mismatch on [<x> 4096] Then it outputs a comparably fewer lines of: free space inode generation (0) did not match free space cache generation (<x>) Finally it outputs: checking fs roots And after some time gets killed by the Linux OOM killer. The system has 4G of memory. The dark irony here is I was trying to btrfs send the subvolumes off of this disk so I could use it for swap space because btrfs send operations on other disks were running out of memory. The filesystem here was likely created with Linux 3.2 and hasn't seen much use for awhile, until today I mounted it to try to btrfs send off those volumes. xaba noted this could be the result of some 3.2-era kernel bug. He recognized the messages I was seeing. If this is the case, and this sort of thing is common, it seems we might want to have a way of detecting this and trying to salvage the situation (particularly as Debian wheezy -- the last Debian stable release -- is on a 3.2 kernel). Either way, I'll wait for a consensus here on how to proceed. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html