bad tree block start, want #### have 0

bad tree block start, want #### have 0

[DrYak]

Hello

I'm having trouble on a BTRFS file system that I use on a Raspberry Pi.
I can still mount and access (nearly all) my data.

The trouble origin itself is probably hardware (flacky USB3-to-mSATA
adapter and/or power stability), not necessarily a bug in BTRFS.

As I've said I can retreive nearly all the data I need, so I could
surely just `btrfs restore` and then rebuild a new filesystem.

BUT...

I wanted to know if it would possible to just repair the filesystem.
(Basically kill the broken extent and/or excise the corresponding tree
leaf).

Are there any way ?

(Again it's not critical, I could btrfs-restore, I just want to know if
it would be possible to clean it instead).



Here are `journalctl` message regarding the failure:

Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): enabling
auto defrag
Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): enabling ssd
optimizations
Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): disk space
caching is enabled
Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): has skinny
extents
Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): bdev
/dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 126, gen 0
Oct 15 20:37:49 marsberry kernel: BTRFS error (device sdb1): bad tree
block start, want 547248750592 have 0
Oct 15 20:37:49 marsberry kernel: BTRFS error (device sdb1): bad tree
block start, want 547248750592 have 0



And here's the read-only check output:

# btrfs check /dev/sdb1
Opening filesystem to check...
Checking filesystem on /dev/sdb1
UUID: 5475b0ac-0010-4875-a0d6-e6641c951f5c
[1/7] checking root items
[2/7] checking extents
checksum verify failed on 547248750592 found E4E3BDB6 wanted 00000000
checksum verify failed on 547248750592 found E4E3BDB6 wanted 00000000
bad tree block 547248750592, bytenr mismatch, want=547248750592, have=0
checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
bad tree block 547248766976, bytenr mismatch, want=547248766976, have=0
owner ref check failed [547248750592 16384]
owner ref check failed [547248766976 16384]
ERROR: errors found in extent allocation tree or chunk allocation
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
bad tree block 547248766976, bytenr mismatch, want=547248766976, have=0
Error going to next leaf -5
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 247339167744 bytes used, error(s) found
total csum bytes: 241066812
total tree bytes: 434569216
total fs tree bytes: 169771008
total extent tree bytes: 16039936
btree space waste bytes: 42891494
file data blocks allocated: 270783406080
 referenced 268366499840



So any way to remove the damnaged data instead of restore/re-mkfs the
still non-damaged one ?

Thanks you!

Re: bad tree block start, want #### have 0

[Qu Wenruo]

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



On 2019/10/16 上午3:03, DrYak wrote:
> Hello
> 
> I'm having trouble on a BTRFS file system that I use on a Raspberry Pi.
> I can still mount and access (nearly all) my data.
> 
> The trouble origin itself is probably hardware (flacky USB3-to-mSATA
> adapter and/or power stability), not necessarily a bug in BTRFS.
> 
> As I've said I can retreive nearly all the data I need, so I could
> surely just `btrfs restore` and then rebuild a new filesystem.
> 
> BUT...
> 
> I wanted to know if it would possible to just repair the filesystem.
> (Basically kill the broken extent and/or excise the corresponding tree
> leaf).

It's not impossible, but not practical under most cases.

> 
> Are there any way ?
> 
> (Again it's not critical, I could btrfs-restore, I just want to know if
> it would be possible to clean it instead).
> 
> 
> 
> Here are `journalctl` message regarding the failure:
> 
> Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): enabling
> auto defrag
> Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): enabling ssd
> optimizations
> Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): disk space
> caching is enabled
> Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): has skinny
> extents
> Oct 15 20:37:20 marsberry kernel: BTRFS info (device sdb1): bdev
> /dev/sdb1 errs: wr 0, rd 0, flush 0, corrupt 126, gen 0
> Oct 15 20:37:49 marsberry kernel: BTRFS error (device sdb1): bad tree
> block start, want 547248750592 have 0
> Oct 15 20:37:49 marsberry kernel: BTRFS error (device sdb1): bad tree
> block start, want 547248750592 have 0

For this block start 0, it means the header of the expected tree block
is all zero.
Normally, either it means the write doesn't reach disk, or a wrong
discard is triggered.

> 
> 
> 
> And here's the read-only check output:
> 
> # btrfs check /dev/sdb1
> Opening filesystem to check...
> Checking filesystem on /dev/sdb1
> UUID: 5475b0ac-0010-4875-a0d6-e6641c951f5c
> [1/7] checking root items
> [2/7] checking extents
> checksum verify failed on 547248750592 found E4E3BDB6 wanted 00000000
> checksum verify failed on 547248750592 found E4E3BDB6 wanted 00000000
> bad tree block 547248750592, bytenr mismatch, want=547248750592, have=0
> checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
> checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
> bad tree block 547248766976, bytenr mismatch, want=547248766976, have=0
> owner ref check failed [547248750592 16384]
> owner ref check failed [547248766976 16384]
> ERROR: errors found in extent allocation tree or chunk allocation

According to the owner ref check line, it's extent tree. So you have
some chance repair it.

Since it's non-critical, please try "btrfs check --init-extent-tree" to
see if it's working.

Thanks,
Qu

> [3/7] checking free space cache
> [4/7] checking fs roots
> [5/7] checking only csums items (without verifying data)
> checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
> checksum verify failed on 547248766976 found 8E4EC148 wanted 00000000
> bad tree block 547248766976, bytenr mismatch, want=547248766976, have=0
> Error going to next leaf -5
> [6/7] checking root refs
> [7/7] checking quota groups skipped (not enabled on this FS)
> found 247339167744 bytes used, error(s) found
> total csum bytes: 241066812
> total tree bytes: 434569216
> total fs tree bytes: 169771008
> total extent tree bytes: 16039936
> btree space waste bytes: 42891494
> file data blocks allocated: 270783406080
>  referenced 268366499840
> 
> 
> 
> So any way to remove the damnaged data instead of restore/re-mkfs the
> still non-damaged one ?
> 
> Thanks you!
> 


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