On Thu, Dec 2, 2021, at 18:33, Eyal Lebedinsky wrote: > I use debugfs to do this. Knowing each fs block range (lo hi) > calculated from the raid mismatch notice: > > I first identify the relevant blocks in each reported range with > debugfs -R "testb $lo $((hi-lo))" $device > then locate the associated inodes with > debugfs -R "icheck $list" $device > and finally discover files in these locations with > debugfs -R "ncheck $inode" $device Thank you very much... this is exactly what I was looking for and it worked brilliantly. For posterity, here's a summary of the process in my case. First I converted the md sector numbers to ext4 block numbers: 2742891144 * 512 / 4096 + 0 = 342861393 And md also told me the mismatches basically covered 5 4KiB contiguous blocks. So... debugfs -R "testb 342861393 5" /dev/md1 told me all 5 blocks were in use. Then using all 5 block numbers... debugfs -R "icheck 342861393 342861394 342861395 342861396 342861397" /dev/md1 gave me a single inode number. Then... debugfs -R "ncheck 299893552" /dev/md1 gave me the filename (e.g.) /videos/00001.MTS Then... cp -a /videos/00001.MTS /tmp && rm /videos/00001.MTS ; debugfs -R "testb 342861393 5" /dev/md1 resulted in those same 5 blocks now *not* being in use. Then echo 2742891144 > /sys/block/md1/md/sync_min echo 2743074816 > /sys/block/md1/md/sync_max # rounded up to next 512KiB chunk echo repair > /sys/block/md1/md/sync_action cat /sys/block/md1/md/sync_completed # only took a couple seconds echo idle > /sys/block/md1/md/sync_action mv /tmp/00001.MTS /videos I was surprised that while I was hitting those sectors, md did not report the mismatches. And I worried that maybe I calculated the wrong blocks. But then I did a check of the entire array overnight, and there were no mismatches reported, for the first time in a year or two of weeks. So I guess it worked. I actully am still a bit confused on when md components are dealing in bytes, sectors or chunks, but in this case it worked out. Anyway, thank you, Eyal!! -Matt
