How to get a redballed drive back online without parity syncs or rebuilds?


Recommended Posts

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.

 

 

Link to comment

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?

 

 

Link to comment

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

 

Link to comment

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.

 

 

Link to comment

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 ?

Link to comment

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.

 

Link to comment

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.

Link to comment

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.

 

Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.