May 1, 201214 yr Emailed the info below to Tom for information on what to do but have not had a reply as yet. Anyone else know what i can do. Thanks So 4.7 was working fine, did a parity check on it before doing any upgrades, everything perfectly fine and has been for a few years working great. So today upgraded to rc-1, upgrade went fine, all drives assigned correctly good to go. Started the array, perfect. So thought I’d do a non correcting parity check to make sure everything was good. This is where the issues started it was so slow at ~17.50MB/sec. 4.7 was ~55.0MB/sec Stopped this after a while and downgraded to 5.0B14. Now the non correcting parity was at ~50.0MB/sec so back to normal(ish) speeds. This went for about 5 hours and then I saw one of the drives had redballed. No clue why. The array showed as started and I was able to stop it without a problem and shutdown. Rebooted and it was still red. Array not started so did a smartctl on the drive, no issues. So I’m assuming that no writes would be occurring with a non correcting check so is there a way to get the drive back to green without any rebuilds or parity check? Would like to get it back online to try again doing a non correcting check to confirm everything with the drives and data is ok.
May 1, 201214 yr Author A smart report came up clean as stated. Which is why i asked the question i did. Want to just bring the drive back online and do a non correcting parity again to check everything again. Mark
May 1, 201214 yr A drive only red-balls when it fails to be written to. At this time, the drive no longer has up-to-date contents on it yet unRAID will continue to update the parity "pretending" it's writing to the data drive. So, you have a drive with incomplete data and a correct drive image due to the parity. Which do you want to use again?
May 1, 201214 yr Author Well a data drive on a non correcting parity should not be being written to unless read errors occur. This check just stopped, array was still started but not doing anything and a redballed drive. smart report showed no errors whatsoever on the redballed drive. This is the reason i want to being the drive back online and do the check again as i believe for some reason a fault with unraid caused this issue. Mark
May 1, 201214 yr It had to be a write. But, if you really must then look up the "Trust My Array" procedure. Please do not come back here complaining about a screwed up drive and data loss after you do it though. The proper thing to do is to attempt a rebuild onto the red-balled disk.
May 1, 201214 yr Emailed the info below to Tom for information on what to do but have not had a reply as yet. Anyone else know what i can do. Thanks So 4.7 was working fine, did a parity check on it before doing any upgrades, everything perfectly fine and has been for a few years working great. So today upgraded to rc-1, upgrade went fine, all drives assigned correctly good to go. Started the array, perfect. So thought I’d do a non correcting parity check to make sure everything was good. This is where the issues started it was so slow at ~17.50MB/sec. 4.7 was ~55.0MB/sec Stopped this after a while and downgraded to 5.0B14. Now the non correcting parity was at ~50.0MB/sec so back to normal(ish) speeds. This went for about 5 hours and then I saw one of the drives had redballed. No clue why. The array showed as started and I was able to stop it without a problem and shutdown. Rebooted and it was still red. Array not started so did a smartctl on the drive, no issues. So I’m assuming that no writes would be occurring with a non correcting check so is there a way to get the drive back to green without any rebuilds or parity check? Would like to get it back online to try again doing a non correcting check to confirm everything with the drives and data is ok. This might be a redundant question but it confused me at first and maybe it confused you to: In 5.0 the shares also get colored balls in front, a red (actually orange) ball means the cache drive needs to write data to it.. You did not by chance made the same mistake I made and looked at this ?
May 1, 201214 yr Author Emailed the info below to Tom for information on what to do but have not had a reply as yet. Anyone else know what i can do. Thanks So 4.7 was working fine, did a parity check on it before doing any upgrades, everything perfectly fine and has been for a few years working great. So today upgraded to rc-1, upgrade went fine, all drives assigned correctly good to go. Started the array, perfect. So thought I’d do a non correcting parity check to make sure everything was good. This is where the issues started it was so slow at ~17.50MB/sec. 4.7 was ~55.0MB/sec Stopped this after a while and downgraded to 5.0B14. Now the non correcting parity was at ~50.0MB/sec so back to normal(ish) speeds. This went for about 5 hours and then I saw one of the drives had redballed. No clue why. The array showed as started and I was able to stop it without a problem and shutdown. Rebooted and it was still red. Array not started so did a smartctl on the drive, no issues. So I’m assuming that no writes would be occurring with a non correcting check so is there a way to get the drive back to green without any rebuilds or parity check? Would like to get it back online to try again doing a non correcting check to confirm everything with the drives and data is ok. This might be a redundant question but it confused me at first and maybe it confused you to: In 5.0 the shares also get colored balls in front, a red (actually orange) ball means the cache drive needs to write data to it.. You did not by chance made the same mistake I made and looked at this ? Nope unfortunately. No mistake here, Don't use a cache drive. Its a drive that has redballed. Sigh....... Wish i had stayed on 4.7, that has worked flawlessly.
May 2, 201214 yr Author It had to be a write. But, if you really must then look up the "Trust My Array" procedure. Please do not come back here complaining about a screwed up drive and data loss after you do it though. The proper thing to do is to attempt a rebuild onto the red-balled disk. How would it be a write on a data disk doing a non correcting parity. Unraid in this situation should not be writing to any drives. The only time i could see that if there was a read error and then internally the drive reallocated a sector which is not the case here.
May 2, 201214 yr Author Does the report show pending or reallocated sectors? Report was clean, no pending or reallocated sectors.
May 2, 201214 yr A drive is only red-balled if a write to the drive fails. You can argue or believe anything you want but that is still the way it is.
May 2, 201214 yr Author A drive is only red-balled if a write to the drive fails. You can argue or believe anything you want but that is still the way it is. That is not always the case. There are posts about cables becoming loose causing a redball. Not my situation. If what you say is true then there is a bug in unraid that tried to write to a disk that it should have only been reading from doing a non-correcting parity check.
May 2, 201214 yr A drive is only red-balled if a write to the drive fails. You can argue or believe anything you want but that is still the way it is. What do you base this on ??
May 2, 201214 yr http://lime-technology.com/wiki/index.php/FAQ#What_does_the_Red_Ball_mean.3F and more info: Disk controller or cable faults that result in loss of communications to one or more drives, causing the drive(s) to be marked Disabled, displayed with a <red> ball, even though they are fine and were not written to A disk drive that fails to spin back up, causing the drive to be marked Disabled, even though it is fine and was not written to http://lime-technology.com/wiki/index.php/Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily
Archived
This topic is now archived and is closed to further replies.