January 1, 201412 yr Author How are you running the script? Copy and paste the terminal session that shows it run. Here you go.
January 1, 201412 yr Author I was following the advice of some here in running a non-correcting parity check, avoiding the blanket assumption that the data drives are always correct. At least this way you have the opportunity to rebuild the data in the event that parity is actually correct. I never found the method to come to this conclusion, though. so I usually run a second check to confirm and then a third to rebuild - not that this has happened often. Just as a matter of interest, when you found that you had sync errors, why were you reluctant to let UnRAID fix them? When you replaced the parity disk and did a new parity sync, that had EXACTLY the same impact as simply running a correcting check ... except that you were "running at risk" while the new parity sync was in process -- whereas the array would have still been protected during a correcting check. As for identifying which files are potentially impacted by sync errors ... it's possible to identify a "set of files" that could possibly be impacted, but it's FAR more likely that none of those files have errors and that the error is simply a sync error on the parity drive. Personally, I never run non-correcting checks. [Why would I NOT want my parity to be correct??] You can read my detailed thoughts on this in the 2nd post here: http://lime-technology.com/forum/index.php?topic=31020.0
January 1, 201412 yr I usually run a second check to confirm and then a third to rebuild As I noted in the more detailed post I referred to above, if you're going to do that, you should be sure you have current checksums of all your data. This lets you easily confirm whether or not there's actually an error in the data rather than the parity drive. But it's FAR more likely that a sync error is simply an incorrect parity bit on the parity drive -- that's why UnRAID's corrections are always on the parity drive. With checksums, if you still want to run non-correcting checks, you could (a) run a non-correcting check; (b) if any sync errors were found, run a checksum verification of all your data; and © assuming all the data's okay, just run a correcting check.
January 2, 201412 yr How are you running the script? Copy and paste the terminal session that shows it run. Here you go. I see where you changed permissions to make the script executable, but I don't see where you actually ran it.
January 2, 201412 yr How are you running the script? Copy and paste the terminal session that shows it run. Here you go. I see where you changed permissions to make the script executable, but I don't see where you actually ran it. Yes. Next enter "detest.sh 1565565768 40" to run the test. chmod is only needed once.
January 2, 201412 yr Author I apologize for being thick. I think you asked me to do the following, and that's what I did. no dice: chmod +x dtest.sh detest.sh 1565565768 40 Should i run this from a different directory? Im running it from /boot. it tells me command not found. How are you running the script? Copy and paste the terminal session that shows it run. Here you go. I see where you changed permissions to make the script executable, but I don't see where you actually ran it. Yes. Next enter "detest.sh 1565565768 40" to run the test. chmod is only needed once.
January 2, 201412 yr I apologize for being thick. I think you asked me to do the following, and that's what I did. no dice: chmod +x dtest.sh detest.sh 1565565768 40 I think there may have just been a typo in dgaschk's instructions. if you remove that extra 'e', does it work?
Archived
This topic is now archived and is closed to further replies.