Hi, On Fri, Jul 05, 2013 at 09:32:05PM +0100, Filipe David Borba Manana wrote: > If we're looking for a metadata item in the tree and the > search fails with return value of 1, and the slot doesn't > point to the first item in the leaf, check if the previous > item in the leaf corresponds to an extent item for the same > object id - if it does, then don't do another tree search > to get it. I'm suspecting this patch to cause some trouble, see https://bugzilla.kernel.org/show_bug.cgi?id=64961 but there were more reports similar to this one: http://www.spinics.net/lists/linux-btrfs/msg29243.html http://www.spinics.net/lists/linux-btrfs/msg29478.html I did a quick analysis in comment 3, the warning pops when there are 0 references, there's no other evidence that the extent should have none. This happens during balance, so far the working hypothesis is that the refcount changes during relocation (eg. subvolume deletion) but is not fixed up in the late reloc phase. fsck finds lots of wrong refcounts, off by one. The kernel warning fires only if the refcount is 0 though there are > 0 expected. So this could mean that the refcount is silently wrong all the time. david -- 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
