On Wed, May 20, 2020 at 5:56 AM Emil Heimpel <broetchenrackete@xxxxxxxxx> 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
