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 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...
> 
> That's why I call it "small chance"
> 
>>
>> The backup snapshots are OK as per original check.
> 
> Then you should be OK to restore.
> 
> Thanks,
> Qu
> 
>>
>>
>> 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
>>>