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

["^m'e" <marcoep@gmail.com>]

Thanks!

Got these

  # ./btrfs.static inspect dump-super -fFa /dev/sdb3 |grep
backup_tree_root: | sort -u
        backup_tree_root:    180410073088    gen: 463765    level: 1
        backup_tree_root:    180415758336    gen: 463766    level: 1
        backup_tree_root:    180416364544    gen: 463767    level: 1
        backup_tree_root:    4194304    gen: 463764    level: 1

but, nada: all have transid failures...

The backup snapshots are OK as per original check.


On Mon, Jan 29, 2018 at 3:09 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
> On 2018年01月29日 22:49, ^m'e wrote:
>> On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo <quwenruo.btrfs@gmx.com> 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,
>>>> and it failed miserably with a nice kernel oops.
>>>>
>>>> So I went for a lowmem repair:
>>>> ----------------------------------------------------------------------------------------
>>>> # ./btrfsck.static check --repair --mode=lowmem /dev/sdb3 2>&1 | tee
>>>> /mnt/custom/rescue/btrfs-recovery/btrfs-repair.BTR-POOL.1.log
>>>> WARNING: low-memory mode repair support is only partial
>>>> Fixed 0 roots.
>>>> checking extents
>>>> checking free space cache
>>>> checking fs roots
>>>> ERROR: failed to add inode 28891726 as orphan item root 257
>>>> ERROR: root 257 INODE[28891726] is orphan item
>>>
>>> At least I need dig the kernel code further to determine if the orphan
>>> inode handling in btrfs-progs is correct or not.
>>>
>>> So there won't be more dirty fix soon.
>>>
>>> Hopefully you could get some good backup and restore the system.
>>>
>>> At least the problem is limited to a very small range, and it's
>>> something we could handle easily.
>>>
>>> Thanks for all your report,
>>> Qu
>>>
>>>
>>
>> Right.
>>
>> Meanwhile, could you please suggest the best course of action? btrfs
>> rescue or restore?
>> I have snapshots of my two subvols (rootfs, home -- now fs-checking
>> them  just in case...)
>
> Don't run --repair any more.
> It seems to make the case worse.
>
> While the RW mount with orphan cleanup abort seems to screwed up the
> filesystem.
>
> In this case, it's pretty hard to recover, but still has small chance.
>
> Use btrfs inspec dump-super to get backup roots:
>
> # btrfs inspect dump-super -fFa <device> |grep backup_tree_root: | sort
> | uniq
>
> And try all the 4 numbers in the following commands:
>
> # btrfs check --tree-root <number> <device>
>
> To see if is there any good one without transid error.
>
> Thanks,
> Qu
>
>>
>> Cheers,
>>
>>   Marco
>>
>



-- 
^m'e