WDC Red with Firmware Version: 80.00A80 Exact, 8 of thems on my array, and have forgotten to disable write cache :/ And all that you decribed is my case.
I understand that it could be a very hard situation for expect an massive data recovery, even if the datas are still here, the fs structure is (partially?) crashed. I don't have a good knowledge on btrfs structure, as i have on some older FS, like AFS (Amiga file system) and FAT, because with childs, i have less time to dig it (like others, we all have only 24hours by day ;) ). As like i said, if anyone have encountered a similar crash, or have any idea, i'm open to every suggestion, as the last tape backup that i have is 5 years old, and my tape library have crashed when restored it on a new disk. So i'm really stuck on that. For futur raid (14Tb WD Gold x3, for the start), i wish to stay on mdadm/raid5 an Btrfs. (because i don't have enought data on Btrfs raid, and it seems it could have somes issues) What is the best practice for max prenvention of this type of corruption/crash? Snapshot stored on different disk and/or external backup, <put any idea here>? This is another question, but i think this time i have to minimize the risk for this futur partition, and i have to make some diging on internet on the subjet, but i'm convicted that this place is a far away better place to ask for some advices thant on forums ;) Thanks for all your time and share. Thierry Le mer. 31 mars 2021 à 08:14, Chris Murphy <li...@colorremedies.com> a écrit : > > I'm going to fill in some details from the multiday conversation with > IRC regulars. We couldn't figure out a way forward. > > * WDC Red with Firmware Version: 80.00A80, which is highly suspected > to deal with power fail and write caching incorrectly, and at least on > Btrfs apparently pretty much always drops writes for critical > metadata. > * A power fail / reset happened > * No snapshots > * --repair and --init-extent-tree may not have done anything because > they didn't complete > * Less than 10% needs to be recovered and it's accepted that it can't > be repaired. The focus is just on a limited restore, but we can't get > past the transid failures. > > > zapan@UBUNTU-SERVER:~$ sudo btrfs check --readonly /dev/md0 > Opening filesystem to check... > parent transid verify failed on 23079040831488 wanted 524940 found 524941 > parent transid verify failed on 23079040831488 wanted 524940 found 524941 > Ignoring transid failure > parent transid verify failed on 23079040319488 wanted 524931 found 524939 > Ignoring transid failure > Checking filesystem on /dev/md0 > UUID: f4f04e16-ce38-4a57-8434-67562a0790bd > [1/7] checking root items > parent transid verify failed on 23079042863104 wanted 423153 found 524931 > parent transid verify failed on 23079042863104 wanted 423153 found 524931 > Ignoring transid failure > ERROR: child eb corrupted: parent bytenr=23079040999424 item=11 parent > level=2 child bytenr=23079042863104 child level=0 > ERROR: failed to repair root items: Input/output error > [2/7] checking extents > parent transid verify failed on 23079042863104 wanted 423153 found 524931 > Ignoring transid failure > ERROR: child eb corrupted: parent bytenr=23079040999424 item=11 parent > level=2 child bytenr=23079042863104 child level=0 > ERROR: errors found in extent allocation tree or chunk allocation > [3/7] checking free space cache > cache and super generation don't match, space cache will be invalidated > [4/7] checking fs roots > root 5 root dir 256 not found > parent transid verify failed on 23079042863104 wanted 423153 found 524931 > Ignoring transid failure > ERROR: child eb corrupted: parent bytenr=23079040999424 item=11 parent > level=2 child bytenr=23079042863104 child level=0 > ERROR: errors found in fs roots > found 0 bytes used, error(s) found > total csum bytes: 0 > total tree bytes: 0 > total fs tree bytes: 0 > total extent tree bytes: 0 > btree space waste bytes: 0 > file data blocks allocated: 0 > referenced 0 > > btrfs-find-root doesn't find many options to work with, and all of > them fail with 'btrfs restore -t' > > > zapan@UBUNTU-SERVER:~$ sudo btrfs-find-root /dev/md0 > parent transid verify failed on 23079040831488 wanted 524940 found 524941 > parent transid verify failed on 23079040831488 wanted 524940 found 524941 > Ignoring transid failure > parent transid verify failed on 23079040319488 wanted 524931 found 524939 > Ignoring transid failure > Superblock thinks the generation is 524941 > Superblock thinks the level is 2 > Found tree root at 23079040999424 gen 524941 level 2 > Well block 23079040327680(gen: 524940 level: 2) seems good, but > generation/level doesn't match, want gen: 524941 level: 2 > Well block 23079040389120(gen: 524939 level: 2) seems good, but > generation/level doesn't match, want gen: 524941 level: 2 > zapan@UBUNTU-SERVER:~$ sudo btrfs restore -viD -t 23079040389120 > /dev/md0 /mnt/raid1/restore/ > parent transid verify failed on 23079040389120 wanted 524941 found 524939 > parent transid verify failed on 23079040389120 wanted 524941 found 524939 > Ignoring transid failure > parent transid verify failed on 23079040323584 wanted 524939 found 524941 > parent transid verify failed on 23079040323584 wanted 524939 found 524941 > Ignoring transid failure > parent transid verify failed on 23079040319488 wanted 524931 found 524939 > Ignoring transid failure > This is a dry-run, no files are going to be restored > Reached the end of the tree searching the directory > zapan@UBUNTU-SERVER:~$ sudo btrfs restore -viD -t 23079040327680 > /dev/md0 /mnt/raid1/restore/ > parent transid verify failed on 23079040327680 wanted 524941 found 524940 > parent transid verify failed on 23079040327680 wanted 524941 found 524940 > Ignoring transid failure > parent transid verify failed on 23079040831488 wanted 524940 found 524941 > parent transid verify failed on 23079040831488 wanted 524940 found 524941 > Ignoring transid failure > parent transid verify failed on 23079040319488 wanted 524931 found 524939 > Ignoring transid failure > This is a dry-run, no files are going to be restored > Reached the end of the tree searching the directory > > > > > > -- > Chris Murphy
