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! >
signature.asc
Description: OpenPGP digital signature
