Re: Need help recovering broken RAID5 array (parent transid verify failed)

From: Chris Murphy <lists@colorremedies.com>
To: Emil Heimpel <broetchenrackete@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Need help recovering broken RAID5 array (parent transid verify failed)
Date: Wed, 20 May 2020 13:01:28 -0600	[thread overview]
Message-ID: <CAJCQCtQi3KZvKGO17YoQ3AroiePjywhhNAFjdKFD0DwL3tkbLg@mail.gmail.com> (raw)
In-Reply-To: <343f7aa9-4cff-45b7-8635-4ca19014c4e5@localhost>

On Wed, May 20, 2020 at 5:56 AM Emil Heimpel <broetchenrackete@gmail.com> wrote:
>
> Hi again,
>
> I ran find-root and using the first found root (that is not in the superblock) seems to be finding data with btrfs-restore (only did a dry-run, because I don't have the space at the moment to do a full restore). At least I got warnings about folders where it stopped looping and I recognized the folders. It is still not showing any files, but maybe I misunderstood what the dry-run option is suppose to be doing.
>
> Because the generation of the root is higher than expected, I don't know which root is expected to be the best option to choose from. One that is closest to the root the super thinks is the correct one (fe 30122555883520(gen: 116442 level: 0)) or the one with the highest generation (30122107502592(gen: 116502 level: 1))? To be honest I don't think I quite understand generations and levels :)

Yeah it's confusing.

I think there's extent tree corruption and I'm not sure it can be
repaired. I suggest 'btrfs restore' until you're satisfied, and then
you can try 'btrfs check --init-extent-tree' and see if it can fix the
extent tree. It's maybe a 50/50 chance, hard to say. If it completes,
follow it up with 'btrfs check' without options, and see if it
complains about anything else.

One thing that's important to consider is using space_cache v2. The
default space_cache v1 puts free space metadata into data chunks,
subjecting them to raid56, which is not great. Since you went to the
effort to use raid1 metadata, best to also use space_cache=v2 at first
mount, putting free space metadata into metadata chunks. It's expected
to be the default soon, I guess, but I'm not sure what the time frame
is.

Also consider using hdparm -W (capital W not lower case, see man page)
to disable the write cache on all drives if you're not certain they
consistently honor FUA or fsync.

-- 
Chris Murphy