Running "btrfs check" on the 3rd of the 4 devices the volume consists of crashes with a trace:
## $ btrfs check --readonly /dev/sdd Opening filesystem to check... parent transid verify failed on 1048576 wanted 60234 found 60230 parent transid verify failed on 1048576 wanted 60234 found 60230 Ignoring transid failure volumes.c:1762: btrfs_chunk_readonly: BUG_ON `!ce` triggered, value 1 btrfs[0x426fdc] btrfs(btrfs_chunk_readonly+0x98)[0x429acd] btrfs(btrfs_read_block_groups+0x1c1)[0x41cd44] btrfs(btrfs_setup_all_roots+0x368)[0x416540] btrfs[0x416a8a] btrfs(open_ctree_fs_info+0xd0)[0x416bcc] btrfs(cmd_check+0x591)[0x45f431] btrfs(main+0x24a)[0x40ca02] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa320a44b35] btrfs[0x40c509] [1] 22848 abort btrfs check --readonly /dev/sdd ## Trying to mount "ro,usebackuproot" shows bad superblock and following errors in /var/log/messages: ## 33814.360633] BTRFS info (device sdd): trying to use backup root at mount time [33814.360637] BTRFS info (device sdd): using free space tree [33814.360638] BTRFS info (device sdd): has skinny extents [33814.361708] BTRFS error (device sdd): parent transid verify failed on 1048576 wanted 60234 found 60230 [33814.361764] BTRFS error (device sdd): failed to read chunk root [33814.373140] BTRFS error (device sdd): open_ctree failed ## Again, thank you very much for all help! Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, March 25, 2019 11:44 PM, berodual_xyz <berodual_...@protonmail.com> wrote: > Thank you very much Hugo, > > the underlying devices are based on HW raid6 and effectively "stitched" > together. Loosing any of those would mean loosing all data, so much is clear. > > My concern was not so much bitrod / silent data corruption but I would not > have expected disabled data checksumming to be a disadvantage at recovering > from the supposed corruption now. > > Does anyone have any input on how to restore files based on inode no. from > the tree dump that I have? > > "usebackuproot,ro" did not succeed either. > > Much appreciate the input! > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Monday, March 25, 2019 11:38 PM, Hugo Mills h...@carfax.org.uk wrote: > > > On Mon, Mar 25, 2019 at 10:26:29PM +0000, berodual_xyz wrote: > > > > > Dear all, > > > on a large btrfs based filesystem (multi-device raid0 - all devices okay, > > > nodatacow,nodatasum...) > > > > Ouch. I think the only thing you could have done to make the FS > > more fragile is mounting with nobarrier(). Frankly, anything you're > > getting off it is a bonus. RAID-0 gives you no duplicate copy, > > nodatacow implies nodatasum, and nodatasum doesn't even give you the > > ability to detect data corruption, let alone fix it. > > With that configuration, I'd say pretty much by definition the > > contents of the FS are considered to be discardable. > > Restoring from backups is the recommended approach with transid > > failures. > > () Don't do that. > > > > > I experienced severe filesystem corruption, most likely due to a hard > > > reset with inflight data. > > > The system cannot mount (also not with "ro,nologreplay" / "nospace_cache" > > > etc.). > > > > Given how close the transids are, have you tried > > "ro,usebackuproot"? That's about your only other option at this > > point. But, if btrfs restore isn't working, then usebacuproot probably > > won't either. > > > > > Running "btrfs restore" I got a reasonable amount of data backed up, but > > > a large chunk is missing. > > > "btrfs check" gives the following error: > > > -- > > > $ btrfs check -b /dev/sdd > > > Opening filesystem to check... > > > parent transid verify failed on 1048576 wanted 60234 found 60230 > > > parent transid verify failed on 1048576 wanted 60234 found 60230 > > > Ignoring transid failure > > > parent transid verify failed on 55432763981824 wanted 60233 found 60235 > > > parent transid verify failed on 55432763981824 wanted 60233 found 60235 > > > Ignoring transid failure > > > parent transid verify failed on 55432753725440 wanted 60232 found 60235 > > > parent transid verify failed on 55432753725440 wanted 60232 found 60235 > > > Ignoring transid failure > > > parent transid verify failed on 55432764063744 wanted 60233 found 60235 > > > parent transid verify failed on 55432764063744 wanted 60233 found 60235 > > > Ignoring transid failure > > > Checking filesystem on /dev/sdd > > > UUID: 8b19ff46-3f42-4f51-be6b-5fc8a7d8f2cd > > > [1/7] checking root items > > > Error: could not find extent items for root 268 > > > ERROR: failed to repair root items: No such file or directory > > > -- > > > I have a complete "dump tree" zip but its a couple of GB. > > > Some sources on the net say to run "btrfs check --init-extent-tree" but I > > > would like to reach out first. > > > > Probably not wise. "Sources on the net" are frequently wrong when > > it comes to btrfs recovery. > > > > > btrfs progs version is 4.20.2 and kernel is 4.20.17 > > > > At least those aren't out of date. The only positive thing here... > > Hugo. > > > > Hugo Mills | I gave up smoking, drinking and sex once. It was the > > hugo@... carfax.org.uk | scariest 20 minutes of my life. > > http://carfax.org.uk/ | > > PGP: E2AB1DE4 |
