On Wednesday 20 of July 2011 16:24:31 you wrote: > My suggestion would be to remove the drive you recently added and then see > if the data is still corrupted. It may not help but is probably worth a > try. tried that, did not help, probably due to the finished rebuild that "repaired" all the parity data > There was a bug prior to 2.6.32 where RAID6 could sometimes write the wrong > data when recovering to a spare. It would only happen if you were accessing > that data at the same time as it was recovery it, and if you were unlucky. I was accessing some data (read-mostly), but now the largest undamaged file on the filesystem has just under 3MB - that looks a bit suspicious, as the stripe- width is 6x 512K = 3M > BTW the monthly scans that you do are primarily for finding sleeping bad > blocks - blocks that you cannot read. They do check for inconsistencies in > the parity but only report them, it doesn't correct them. This is because > automatically correcting can cause more problems than it solves. > > When the monthly check reported inconsistencies you "should" have confirmed > that all the drives seem to be functioning correctly and then run a 'repair' > pass to fix the parity blocks up. > > As you didn't that bad parity would have created bad data when you > recovered. see the last part, at this point I would be perfectly OK with 72 damaged blocks, as per the last scan (or even a few hundred, for that matter) PS: forgot to include maillist -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
