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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
