You are not logged in.
As described in the wiki article on RAID scrubbing, I've been running regular checks on my RAID5. This time, rather than 0, the mismatch_cnt file showed many bad sectors:
cat /sys/block/md7/md/mismatch_cnt
3088If I've understood correctly, the wiki specifies this as the parity and the data block not agreeing with one another, and it not being possible to determine which of the two (if any) is correct. So running repair (rather than check) in sync_action could possibly corrupt the data - and the affected blocks are seemingly logged, so the administator of the RAID could later inspect them and choose the correct blocks. But...
In which way could I "inspect" the bad sectors or blocks? As far as I can find out, the only information available to me is the number of mismatched blocks, rather than the exact location and possible configuration. How could I make sure I'm not corrupting my files when echoing repair to sync_action, as the wiki mentions? How and where could I inspect the exact block mismatches, and is it possible to attempt many different recoveries to check for a sort of, uh, complete file to come out somehow?
Most of my data "seems fine", as in, mpv reports no errors or missing frames, archives still extract, games still run, and audacity can still (at least only with the old set of bugs) open project files and play them.
Basically: Which actions should I take after check, but before repair, to ensure I'm not resolving the mismatched blocks by writing the corrupt block? Is there a way to essentially reconstruct many different possible filesystems based on the possible combinations of blocks, and then somehow look for corrupt files to then somehow determine in which case the data or the parity block is the correct one?
Additionally, higher RAID levels like RAID6 would further mitigate this situation by having more than one parity block per data block, is that correct?
Thanks for your time, I hope I didn't grossly misunderstand everything.
Offline