Yes, you are right, after running `btrfs check --clear-space-cache v1
<dev>` a `btrfs check --readonly` passes without error. Thanks!

I'm absolutely not familiar with the btrfs code, but would it be
possible to have some error handling in `btrfs check` that picks up
this situation instead of crashing?

On Sat, Jun 30, 2018 at 10:07 PM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
>
>
> On 2018年07月01日 09:59, Lewis Diamond wrote:
>> Hi,
>> I've been told to report this issue to this mailing list.
>>
>> sudo btrfs check --readonly /dev/sdc
>> Checking filesystem on /dev/sdc
>> UUID: 2630aec8-8399-4bd8-9397-8c04953a35d5
>> checking extents
>> checking free space cache
>> there is no free space entry for 1596152365056-1596152381440
>> there is no free space entry for 1596152365056-1597220323328
>> cache appears valid but isn't 1596146581504
>> there is no free space entry for 1613348585472-1613348618240
>> there is no free space entry for 1613348585472-1614400192512
>> cache appears valid but isn't 1613326450688
>> block group 1645538705408 has wrong amount of free space, free space
>> cache has 58212352 block group has 58277888
>> failed to load free space cache for block group 1645538705408
>> block group 1683119669248 has wrong amount of free space, free space
>> cache has 52838400 block group has 52953088
>> failed to load free space cache for block group 1683119669248
>> btrfs: unable to add free space :-17
>
> Your free space cache is corrupted.
> And if not handled well, it could (may have already) damaged your fs
> further.
>
> You could try "btrfs check --clear-space-cache v1 <dev>" to remove the
> free space cache completely and re-try "btrfs check --readonly" to see
> if it works.
>
> Thanks,
> Qu
>
>> free-space-cache.c:843: btrfs_add_free_space: BUG_ON `ret == -EEXIST`
>> triggered, value 1
>> btrfs(+0x37337)[0x556024d5d337]
>> btrfs(btrfs_add_free_space+0x11d)[0x556024d5da2d]
>> btrfs(load_free_space_cache+0xde9)[0x556024d5e889]
>> btrfs(cmd_check+0x15fe)[0x556024d8b9ee]
>> btrfs(main+0x88)[0x556024d38768]
>> /usr/lib/libc.so.6(__libc_start_main+0xeb)[0x7f9382a9506b]
>> btrfs(_start+0x2a)[0x556024d3888a]
>> Aborted
>>
>>
>> This happened on a USB HDD duo in raid 1 which had btrfs issues
>> (probably due to a bad controller). One of the hdd was subsequently
>> dropped by a 2 year old (causing subsequent checks to crash).
>>
>> -Lewis
>> --
>> 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
>>
>
--
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