Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Finally restored by merging the last snapshot with what btrfs restore gave me -- surprisingly almost the whole bunch of it :-) Thanks for helping! Cheers, Marco Qu Wenruo wrote on 2018-01-30 02:24: > > > On 2018年01月30日 02:16, ^m'e wrote: >> Thanks! >> >> Got these >> >> # ./btrfs.static

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月30日 02:16, ^m'e wrote: > Thanks! > > Got these > > # ./btrfs.static inspect dump-super -fFa /dev/sdb3 |grep > backup_tree_root: | sort -u > backup_tree_root:180410073088gen: 463765level: 1 > backup_tree_root:180415758336gen: 463766level: 1 >

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks! Got these # ./btrfs.static inspect dump-super -fFa /dev/sdb3 |grep backup_tree_root: | sort -u backup_tree_root:180410073088gen: 463765level: 1 backup_tree_root:180415758336gen: 463766level: 1 backup_tree_root:180416364544gen:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月29日 23:08, ^m'e wrote: > Lowmem check on my backup pool reports dozens of 'backref lost' on > extents... Excerpt: > -- > # ./btrfsck.static check --mode=lowmem /dev/sda1 > checking extents > ERROR: data extent[33866182656 4096]

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Lowmem check on my backup pool reports dozens of 'backref lost' on extents... Excerpt: -- # ./btrfsck.static check --mode=lowmem /dev/sda1 checking extents ERROR: data extent[33866182656 4096] backref lost ERROR: data extent[37102219264

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月29日 22:49, ^m'e wrote: > On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo wrote: >> >> >> On 2018年01月29日 21:58, ^m'e wrote: >>> Thanks for the advice, Qu! >>> >>> I used the system for a while, did some package upgrades -- writing in >>> the suspect corrupted area.

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo wrote: > > > On 2018年01月29日 21:58, ^m'e wrote: >> Thanks for the advice, Qu! >> >> I used the system for a while, did some package upgrades -- writing in >> the suspect corrupted area. Then tried a btrfs-send to my backup vol, >>

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月29日 21:58, ^m'e wrote: > Thanks for the advice, Qu! > > I used the system for a while, did some package upgrades -- writing in > the suspect corrupted area. Then tried a btrfs-send to my backup vol, > and it failed miserably with a nice kernel oops. > > So I went for a lowmem

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks for the advice, Qu! I used the system for a while, did some package upgrades -- writing in the suspect corrupted area. Then tried a btrfs-send to my backup vol, and it failed miserably with a nice kernel oops. So I went for a lowmem repair:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月26日 23:15, ^m'e wrote: > On Fri, Jan 26, 2018 at 12:16 PM, Qu Wenruo wrote: >> Branch updated, problem in 1399 should be fixed. >> >> Seems the remaining problems are less and less now. >> >> Thanks, >> Qu >> > > Great! The fix worked, and repair goes

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On Fri, Jan 26, 2018 at 12:16 PM, Qu Wenruo wrote: > Branch updated, problem in 1399 should be fixed. > > Seems the remaining problems are less and less now. > > Thanks, > Qu > Great! The fix worked, and repair goes throught at last :-) though we're still left with some

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Branch updated, problem in 1399 should be fixed. Seems the remaining problems are less and less now. Thanks, Qu On 2018年01月26日 19:19, ^m'e wrote: > On Thu, Jan 25, 2018 at 11:30 PM, Qu Wenruo wrote: >> >> Please provide dump for this: >> >> # btrfs inspect dump-tree -t

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On Thu, Jan 25, 2018 at 11:30 PM, Qu Wenruo wrote: > > Please provide dump for this: > > # btrfs inspect dump-tree -t 1399 | grep -C 20 18446744073709551615 > This gives nothing. > And > > # btrfs inspect dump-tree -t 1399 | grep -C 20 30039322 > This gives:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月26日 00:40, ^m'e wrote: > Quite some progress, thanks :-) > > The check: > --- > # ./btrfs.static check --mode=lowmem /dev/sdb3 2>&1 | tee > /mnt/custom/rescue/btrfs-recovery/btrfs-check.3.log > checking extents > checking free space

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Quite some progress, thanks :-) The check: --- # ./btrfs.static check --mode=lowmem /dev/sdb3 2>&1 | tee /mnt/custom/rescue/btrfs-recovery/btrfs-check.3.log checking extents checking free space cache checking fs roots ERROR: root 1385

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月25日 20:29, ^m'e wrote: > No luck this time: > > # ./btrfs-corrupt-block.static -X /dev/sdb3 > ERROR: Failed to unlink the old file "Manifest": No such file or directory > extent buffer leak: start 4210688 len 16384 > extent_io.c:607: free_extent_buffer_internal: BUG_ON `eb->flags & >

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

No luck this time: # ./btrfs-corrupt-block.static -X /dev/sdb3 ERROR: Failed to unlink the old file "Manifest": No such file or directory extent buffer leak: start 4210688 len 16384 extent_io.c:607: free_extent_buffer_internal: BUG_ON `eb->flags & EXTENT_DIRTY` triggered, value 1 [0x416a32]

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Confirmed same problem as previous root. So branch updated to fix the same problem for root 257. Please try and see if the following error message is gone: -- ERROR: root 257 DIR_ITEM[30039322 4007295565] couldn't find relative INODE_ITEM[0] namelen 0 filename filetype 0 ERROR: root 257

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Here it is: --- # ./btrfs-debug-tree.static -t 257 /dev/sdb3 | grep -C 20 30039322 | tee /mnt/custom/rescue/btrfs-recovery/btrfs-debug.30039322.t257.log location key (30037910 INODE_ITEM 0) type DIR transid 136248 data_len 0 name_len 3

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月25日 04:41, ^m'e wrote: > And here it is: > > > # ./btrfs-debug-tree.static -t 1385 /dev/sdb3 | grep -C 20 30039322 | In fact, that's only dump tree 1385. Now we also need the dump of tree 257. Thanks, Qu > tee

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月25日 03:00, ^m'e wrote: > The complete check: > > Checking filesystem on /dev/sdb3 > UUID: de1723e2-150c-4448-bb36-be14d7d96093 > ERROR: extent[64368619520, 524288] referencer count mismatch (root: > 257, owner: 7804556, offset: 212992) wanted: 1, have: 0 > ERROR: data

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

And here it is: # ./btrfs-debug-tree.static -t 1385 /dev/sdb3 | grep -C 20 30039322 | tee /mnt/custom/rescue/btrfs-recovery/btrfs-debug.30039322.2.log location key (30037910 INODE_ITEM 0) type DIR transid 136248 data_len 0 name_len 3

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

My bad, forgot to check out the correct branch. Recloned, compiled and fixed. Then rechecking: --- # btrfs check --mode=lowmem /dev/sdb3 Checking filesystem on /dev/sdb3 UUID: de1723e2-150c-4448-bb36-be14d7d96093 checking extents ERROR:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月24日 19:57, ^m'e wrote: > Thanks Qu! > > I did it (had to add 'progs_extra' to the 'static' make target...), > but it looks like there's something missing: Did you check out the branch called "dirty_fix"? Thanks, Qu > > -

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks Qu! I did it (had to add 'progs_extra' to the 'static' make target...), but it looks like there's something missing: - # ./btrfs-corrupt-block.static -X /dev/sdb3 ./btrfs-corrupt-block.static: invalid option -- 'X' usage:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Here is the super dirty tricky fix (and less deadly now). https://github.com/adam900710/btrfs-progs/tree/dirty_fix Please compile the branch and run: # ./btrfs-corrupt-block -X Where must be unmounted, the original btrfs-corrupt-block tool doesn't have mount check, and I'm too lazy to add

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Qu Wenruo wrote on 2018-01-24 09:49: > Sorry for the late reply, I was off yesterday. > No problem :-) Booted normally today, system up, but see this (I forgot to stop the snapshot cron task...) [ 115.127961] BTRFS error (device sdb3): Send: inconsistent snapshot, found deleted reference for

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Sorry for the late reply, I was off yesterday. On 2018年01月22日 23:04, ^m'e wrote: > Thanks for the quick reply, Qu! > > I forgot to say that I see weird characters in the btrfs check repair > in lines "ERROR: DIR_ITEM... name ..." output. Although that can be > due to corruption, I seem to

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

Thanks for the quick reply, Qu! I forgot to say that I see weird characters in the btrfs check repair in lines "ERROR: DIR_ITEM... name ..." output. Although that can be due to corruption, I seem to remember that a previous version of btrfs-progs I used didn't show that... I also see:

Re: btrfs check: backref lost, mismatch with its hash -- can't repair

On 2018年01月22日 22:11, ^m'e wrote: > Hi there, > > After resuming from hibernation, my system shows weirdness; the > following dmesg line alerted me: > > Jan 22 08:10:33 [kernel] BTRFS critical (device sdb3): invalid dir > item name + data len: 3 + 32907 This is true problem. No dir item

btrfs check: backref lost, mismatch with its hash -- can't repair

Hi there, After resuming from hibernation, my system shows weirdness; the following dmesg line alerted me: Jan 22 08:10:33 [kernel] BTRFS critical (device sdb3): invalid dir item name + data len: 3 + 32907 Although I can boot (root is BTRFS), (re-)mount the concerned FS, succesfully scrub it