btrfs check --readonly crash

btrfs check --readonly crash

[Lewis Diamond]

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

Re: btrfs check --readonly crash

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 2215 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: btrfs check --readonly crash

[Lewis Diamond]

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

Re: btrfs check --readonly crash

[Chris Murphy]

On Sun, Jul 1, 2018 at 12:01 PM, Lewis Diamond <me@lewisdiamond.com> wrote:
> 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?

It shouldn't crash, but also you didn't say what version of
btrfs-progs you're using so it's plausible it's already been fixed.
It's worth trying btrfs-progs 4.17 to see if it still crashes, and if
it does still crash, then take a btrfs-image (using -ss option) so
developers have a chance of making btrfs better.




-- 
Chris Murphy

Re: btrfs check --readonly crash

[Qu Wenruo]

[-- Attachment #1.1: Type: text/plain, Size: 3100 bytes --]



On 2018年07月02日 02:01, Lewis Diamond wrote:
> 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?

Patch submitted already:
https://patchwork.kernel.org/patch/10498479/

Thanks,
Qu

> 
> On Sat, Jun 30, 2018 at 10:07 PM, Qu Wenruo <quwenruo.btrfs@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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]