BTRFS critical / corrupt leaf

BTRFS critical / corrupt leaf

[Ondřej Váňa]

Hello!
I've ran into an issue mounting my /home due to this error:
`[ 1567.750050] BTRFS critical (device sdb5): corrupt leaf:
block=135314751488 slot=67 extent bytenr=101613793280 len=134217728
invalid generation, have 500462508591547182 expect (0, 222245]`

Now before seeing the note about contacting the mailing list, I did
run `btrfs check --repair /dev/sdb5`, though it did not find or
correct any errors.

Tried booting older kernels from snapshots and the issue persists.

Now some time between my restarts, the error trying to mount stopped
displaying the corrupt leaf error and now says there's an unclean
windows filesystem or just 'mount: /home: wrong fs type, bad option,
bad superblock on /dev/sdb5, missing codepage or helper program, or
other error.', but the partition is certainly btrfs.

Here's the required output:
```
kachna:/oops # uname -a
Linux kachna.kachna 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC
2020 (556a6fe) x86_64 x86_64 x86_64 GNU/Linux
kachna:/oops #   btrfs --version
btrfs-progs v5.4
kachna:/oops #   btrfs fi show
Label: none  uuid: 7dc4b27d-8946-418f-a790-a3eeeac213ba
       Total devices 1 FS bytes used 23.54GiB
       devid    1 size 30.00GiB used 27.55GiB path /dev/sdb3

Label: 'Home'  uuid: 1c0257d6-77ea-4d0c-ad16-2b99114f4e5e
       Total devices 1 FS bytes used 128.05GiB
       devid    1 size 163.47GiB used 140.02GiB path /dev/sdb5

kachna:/oops #   btrfs fi df /home
ERROR: not a btrfs filesystem: /home
```

I did read through some seemingly related mailing list threads, tried
running on individual RAM modules to see if one of them could be
faulty but nothing seems to make a difference.

Is there any way to recover the partition?

Cheers!

Re: BTRFS critical / corrupt leaf

[Qu Wenruo]

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



On 2020/1/22 上午11:29, Ondřej Váňa wrote:
> Hello!
> I've ran into an issue mounting my /home due to this error:
> `[ 1567.750050] BTRFS critical (device sdb5): corrupt leaf:
> block=135314751488 slot=67 extent bytenr=101613793280 len=134217728
> invalid generation, have 500462508591547182 expect (0, 222245]`

This looks like an error caused by older kernel.

So I guess your fs is created some time ago right?

> 
> Now before seeing the note about contacting the mailing list, I did
> run `btrfs check --repair /dev/sdb5`, though it did not find or
> correct any errors.

You need btrfs-progs v5.4.1 to "detect" the problem.
But repair needs to be done using this branch:
https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair

> 
> Tried booting older kernels from snapshots and the issue persists.
> 
> Now some time between my restarts, the error trying to mount stopped
> displaying the corrupt leaf error and now says there's an unclean
> windows filesystem or just 'mount: /home: wrong fs type, bad option,
> bad superblock on /dev/sdb5, missing codepage or helper program, or
> other error.', but the partition is certainly btrfs.
> 
> Here's the required output:
> ```
> kachna:/oops # uname -a
> Linux kachna.kachna 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC
> 2020 (556a6fe) x86_64 x86_64 x86_64 GNU/Linux
> kachna:/oops #   btrfs --version
> btrfs-progs v5.4
> kachna:/oops #   btrfs fi show
> Label: none  uuid: 7dc4b27d-8946-418f-a790-a3eeeac213ba
>        Total devices 1 FS bytes used 23.54GiB
>        devid    1 size 30.00GiB used 27.55GiB path /dev/sdb3
> 
> Label: 'Home'  uuid: 1c0257d6-77ea-4d0c-ad16-2b99114f4e5e
>        Total devices 1 FS bytes used 128.05GiB
>        devid    1 size 163.47GiB used 140.02GiB path /dev/sdb5
> 
> kachna:/oops #   btrfs fi df /home
> ERROR: not a btrfs filesystem: /home
> ```
> 
> I did read through some seemingly related mailing list threads, tried
> running on individual RAM modules to see if one of them could be
> faulty but nothing seems to make a difference.
> 
> Is there any way to recover the partition?

You can just mount use v5.3 kernel without problem.

Then locate the file owning that extent by:
# btrfs ins logical-resolve 101613793280 </mnt>

Then remove all involved files if they are not important.
Or just rewrite them with the same content.

Then the fs should be gone.

Alternatively, you can try that mentioned branch to repair it, but the
above logical-resolve and delete method should be safer than that
experimental branch.

Thanks,
Qu

> 
> Cheers!
> 


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

Re: BTRFS critical / corrupt leaf

[Qu Wenruo]

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



On 2020/1/22 上午11:39, Qu Wenruo wrote:
> 
> 
> On 2020/1/22 上午11:29, Ondřej Váňa wrote:
>> Hello!
>> I've ran into an issue mounting my /home due to this error:
>> `[ 1567.750050] BTRFS critical (device sdb5): corrupt leaf:
>> block=135314751488 slot=67 extent bytenr=101613793280 len=134217728
>> invalid generation, have 500462508591547182 expect (0, 222245]`
> 
> This looks like an error caused by older kernel.
> 
> So I guess your fs is created some time ago right?
> 
>>
>> Now before seeing the note about contacting the mailing list, I did
>> run `btrfs check --repair /dev/sdb5`, though it did not find or
>> correct any errors.
> 
> You need btrfs-progs v5.4.1 to "detect" the problem.
> But repair needs to be done using this branch:
> https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair
> 
>>
>> Tried booting older kernels from snapshots and the issue persists.
>>
>> Now some time between my restarts, the error trying to mount stopped
>> displaying the corrupt leaf error and now says there's an unclean
>> windows filesystem or just 'mount: /home: wrong fs type, bad option,
>> bad superblock on /dev/sdb5, missing codepage or helper program, or
>> other error.', but the partition is certainly btrfs.
>>
>> Here's the required output:
>> ```
>> kachna:/oops # uname -a
>> Linux kachna.kachna 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC
>> 2020 (556a6fe) x86_64 x86_64 x86_64 GNU/Linux
>> kachna:/oops #   btrfs --version
>> btrfs-progs v5.4
>> kachna:/oops #   btrfs fi show
>> Label: none  uuid: 7dc4b27d-8946-418f-a790-a3eeeac213ba
>>        Total devices 1 FS bytes used 23.54GiB
>>        devid    1 size 30.00GiB used 27.55GiB path /dev/sdb3
>>
>> Label: 'Home'  uuid: 1c0257d6-77ea-4d0c-ad16-2b99114f4e5e
>>        Total devices 1 FS bytes used 128.05GiB
>>        devid    1 size 163.47GiB used 140.02GiB path /dev/sdb5
>>
>> kachna:/oops #   btrfs fi df /home
>> ERROR: not a btrfs filesystem: /home
>> ```
>>
>> I did read through some seemingly related mailing list threads, tried
>> running on individual RAM modules to see if one of them could be
>> faulty but nothing seems to make a difference.
>>
>> Is there any way to recover the partition?
> 
> You can just mount use v5.3 kernel without problem.
> 
> Then locate the file owning that extent by:
> # btrfs ins logical-resolve 101613793280 </mnt>
> 
> Then remove all involved files if they are not important.
> Or just rewrite them with the same content.
> 
> Then the fs should be gone.

s/fs/problem/

> 
> Alternatively, you can try that mentioned branch to repair it, but the
> above logical-resolve and delete method should be safer than that
> experimental branch.
> 
> Thanks,
> Qu
> 
>>
>> Cheers!
>>
> 


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

Re: BTRFS critical / corrupt leaf

[Qu Wenruo]

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



On 2020/1/22 下午1:13, Ondřej Váňa wrote:
> Thank you for the quick response, it has been created a few years ago
> indeed, I booted up an older installation I had around and could find a
> single file using the 'btrfs ins logical-resolve 101613793280 </mnt>',
> removed it and all is in a good shape now. 
> Is there something I should do to prevent this from happening again?
> Such as recreating the filesystem or should it be somehow "updated"?

It looks like a bug in much older kernel, so as long as that bug is
fixed, you don't need to bother any more.

Just to be extra safe, run btrfs check on the fs with v5.4.1 to ensure
there is no other similar problems, then you can call it a day.

Thanks,
Qu

> 
> Thanks again! 
> 
> On Tue., Jan. 21, 2020, 19:39 Qu Wenruo <quwenruo.btrfs@gmx.com
> <mailto:quwenruo.btrfs@gmx.com>> wrote:
> 
> 
> 
>     On 2020/1/22 上午11:29, Ondřej Váňa wrote:
>     > Hello!
>     > I've ran into an issue mounting my /home due to this error:
>     > `[ 1567.750050] BTRFS critical (device sdb5): corrupt leaf:
>     > block=135314751488 slot=67 extent bytenr=101613793280 len=134217728
>     > invalid generation, have 500462508591547182 expect (0, 222245]`
> 
>     This looks like an error caused by older kernel.
> 
>     So I guess your fs is created some time ago right?
> 
>     >
>     > Now before seeing the note about contacting the mailing list, I did
>     > run `btrfs check --repair /dev/sdb5`, though it did not find or
>     > correct any errors.
> 
>     You need btrfs-progs v5.4.1 to "detect" the problem.
>     But repair needs to be done using this branch:
>     https://github.com/adam900710/btrfs-progs/tree/extent_gen_repair
> 
>     >
>     > Tried booting older kernels from snapshots and the issue persists.
>     >
>     > Now some time between my restarts, the error trying to mount stopped
>     > displaying the corrupt leaf error and now says there's an unclean
>     > windows filesystem or just 'mount: /home: wrong fs type, bad option,
>     > bad superblock on /dev/sdb5, missing codepage or helper program, or
>     > other error.', but the partition is certainly btrfs.
>     >
>     > Here's the required output:
>     > ```
>     > kachna:/oops # uname -a
>     > Linux kachna.kachna 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC
>     > 2020 (556a6fe) x86_64 x86_64 x86_64 GNU/Linux
>     > kachna:/oops #   btrfs --version
>     > btrfs-progs v5.4
>     > kachna:/oops #   btrfs fi show
>     > Label: none  uuid: 7dc4b27d-8946-418f-a790-a3eeeac213ba
>     >        Total devices 1 FS bytes used 23.54GiB
>     >        devid    1 size 30.00GiB used 27.55GiB path /dev/sdb3
>     >
>     > Label: 'Home'  uuid: 1c0257d6-77ea-4d0c-ad16-2b99114f4e5e
>     >        Total devices 1 FS bytes used 128.05GiB
>     >        devid    1 size 163.47GiB used 140.02GiB path /dev/sdb5
>     >
>     > kachna:/oops #   btrfs fi df /home
>     > ERROR: not a btrfs filesystem: /home
>     > ```
>     >
>     > I did read through some seemingly related mailing list threads, tried
>     > running on individual RAM modules to see if one of them could be
>     > faulty but nothing seems to make a difference.
>     >
>     > Is there any way to recover the partition?
> 
>     You can just mount use v5.3 kernel without problem.
> 
>     Then locate the file owning that extent by:
>     # btrfs ins logical-resolve 101613793280 </mnt>
> 
>     Then remove all involved files if they are not important.
>     Or just rewrite them with the same content.
> 
>     Then the fs should be gone.
> 
>     Alternatively, you can try that mentioned branch to repair it, but the
>     above logical-resolve and delete method should be safer than that
>     experimental branch.
> 
>     Thanks,
>     Qu
> 
>     >
>     > Cheers!
>     >
> 


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