Resurrecting this old thread because I'm still seeing these errors.

On Thu, Mar 16, 2017 at 6:54 PM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
>
>
> At 03/17/2017 07:22 AM, Chris Murphy wrote:
>>
>> With kernel 4.10.3, and btrfs-progs 4.10, I'm still seeing the
>> following errors only with --mode=lowmem with a single device volume.
>>
>>
>> ERROR: data extent[16913485824 7577600] backref lost
>> (hundreds of lines of the same thing)
>>
>> btrfs-image (no errors reported during capture) 518MiB
>> https://drive.google.com/open?id=0B7NttHfq6wAJd3ZXM3AxS0dVQlU
>
>
> Thanks a lot for the image.
>
> Turns out to be that, lowmem mode only checks EXTENT_DATA_REF key, and
> doesn't check SHARED_DATA_REF_KEY, this leads to the error message.
>
> Fix will be sent out soon.


I'm using btrfs-progs 4.13.3 and still see these errors. Do you need
an updated sanitized image, or newer version or patchset to test?

This example error is happening on a single device volume with DUP
metadata, and also ends in a crash:.

ERROR: data extent[16913485824 7577600] backref lost
...
backref.c:466: __add_missing_keys: Assertion `ref->root_id` failed, value 0
...

Complete output, with filtered btrfs-debug-tree info for extent
address 16913485824
https://drive.google.com/open?id=1WgHdIz7zu_bO6evUBkG4wPxpJfwaFCxv

------

This example error is happening on a two device raid1 data and raid1
metadata volume:

ERROR: extent[366498091008, 134217728] referencer count mismatch
(root: 827, owner: 73782, offset: 134217728) wanted: 4, have: 26

Complete output, with filtered btrfs-debug-tree info for extent
address 366498091008.
https://drive.google.com/open?id=1LUMtLIc1LcXhYN3twFcxTyFuJ6ScMlyQ


Both examples have multiple extents reported in the error but I've
only included debug tree info for the first extent listed by lowmem
check. So it's an incomplete report. I can provide sanitized
btrfs-image on request, or test with patches.

-- 
Chris Murphy
--
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

Reply via email to