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.bt...@gmx.com> wrote: >>> >>> >>> On 2018年01月29日 22:49, ^m'e wrote: >>>> On Mon, Jan 29, 2018 at 2:04 PM, Qu Wenruo <quwenruo.bt...@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 >>>
signature.asc
Description: OpenPGP digital signature
