On Fri, Nov 29, 2013 at 3:45 PM, David Sterba <dste...@suse.cz> wrote: > 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
Hi David, What makes you believe the problem is exactly in this function? I read it again, and I can't see how it can miss an extent item that it couldn't before, specially without skinny metadata enabled. Did the fs had skinny metadata enabled? thanks > > 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 -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
