On Sun, Sep 03, 2017 at 03:26:34AM +0000, Josef Bacik wrote: > I was looking through the code for other ways to cut down memory usage when I > noticed we only catch improper re-allocations, not adding another ref for > metadata which is what I suspect your problem is. I added another patch and > pushed it out, sorry for the churn.
Installed. For now, I've seen this once, but otherwise no issues: Dropping a ref for a root that doesn't have a ref on the block Dumping block entry [26538725376 4096], num_refs 2, metadata 0, from disk 1 Ref root 0, parent 29818880, owner 23608, offset 0, num_refs 18446744073709551615 Ref root 0, parent 202129408, owner 23608, offset 0, num_refs 1 Ref root 418, parent 0, owner 23608, offset 0, num_refs 1 Root entry 418, num_refs 1 Root entry 69809, num_refs 0 Ref action 1, root 418, ref_root 0, parent 202129408, owner 23608, offset 0, num_refs 1 No stacktrace support Ref action 2, root 69809, ref_root 0, parent 29818880, owner 23608, offset 0, num_refs 18446744073709551615 No stacktrace support I'm assuming this was done by your patch? Should I worry about 'No stacktrace support' ? Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- 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