Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

I've noticed a red ball on 'disk1'

Featured Replies

Hi there. A week ago, I had noticed on my backup unraid server that 'disk1' had a red ball on it. I did the obvious and unassigned, reassigned the all disks (to be sure), restarted the unraid server, checked to see if the drives appear in BIOS (which they all appear detected in BIOS and in the addmon SATA RAID card as well), replaced the SATA cable connecting disk1 with a new SATA cable (to no avail in resolution), I've reseated all SATA/Power connectors too. I ran a SMART report using he 'smartctl' utility and I've also uploaded the report and my latest syslog file.

I can still write to my 'suspect' disk perfectly fine, getting about 30MB/s to 60MB/s in random tests. (Directly to the disk and with the main share. All tests involved the Parity drive too). I'm concerned it is not 100% and/or it's on its way out. The raid is slowing running out of disk space and I was planning of replacing both the parity and the suspect drive to increase the raid size. The server is a HP Compaq DC7100 PC, which I managed to cram 3 Seagate 1TB 7200 disks into (without modding or squashing components and has been running with this configuration for over a year (It was a FressNAS server 6 months before it saw the light of unRAID).

I was tempted to run a embedded Disk Utility within the HP BIOS, but I hadn't in fear it might destroy all data on my disks. I'm suspecting that the actual drive might be slowly on its way, seeing I can still read/write from it OK, but I cannot see any wrong with the SMART report (or at lease I cannot see anything wrong with it). This server is a backup server of all critical files on my existing main unraid server. I also think that the reduced form factor of this PC might of played a part in the possible life reduction of this disk, as in summur time, I've seen the disks within this server run up to 46C, though it isn't on 24/7 (In fact it only runs about 12 hours a week for the scheduled backup) but I've read on this forum that this particular isn't considered at dangerous as running dsisk at +50C or even 60C. Finally I'm running unRAID 4.5.1. Any suggestions? Cheers.

syslog-20100809-000012.zip

smart.txt

If a disk is disabled (turns red) it will not return to a normal (green ball) state by itself.

 

A drive will turn red when there is a bad write to the drive or if the drive does not respond.

 

The first thing to do is take a syslog. Then shutdown the server, reseat/replace cables, boot, and then run a smartest. You've done all this and your Smart report looks fine definitely pointing towards a loose or bad cable (which hopefully you fixed)

 

At this point you have a few different options.

 

1. Copy the data off of the simulated disk onto another array disk or to a workstation. This does not fix anything but is a good safety measure.

 

2.  Run the "trust my parity procedure. This is a good idea if you know you have not written any data to the simulated disk.

 

3. Allow unRaid to rebuild the failed disk. To do this, stop the array, unassign the disk, start the array, stop the array, reassign the disk. unRaid will then offer the rebuild option. (NOTE - Do NOT press a button called restore at any time in this procedure.)

 

Good luck!

Just to point out the obvious. unRAID is written to protect against a disk failure. When a disk fails, you will still have access to the data that was on that disk and you can still "virtually" write to that disk. The parity disk and the other data disks are used to contruct the disk1 contents you are trying to access on the fly. You now do not have any protection against another disk failing. The red ball means the disk has failed an attempt to write to it and unRAID has taken it out of service. You need to get the red ball corrected before you experience another failure and lose data.

 

 

Your SMART data seems OK so best now to stop array, unassign disk1, start array, stop array, re-assign disk1. Then go back to the main tab and check the "are you sure" box and start the array again. Allow unRAID to attempt to rebuild the disk. See what happens. If it begins to work correctly then it seems you had a cable or connection problem.

 

Peter

 

I can still write to my 'suspect' disk perfectly fine, getting about 30MB/s to 60MB/s in random tests. (Directly to the disk and with the main share. All tests involved the Parity drive too). I'm concerned it is not 100% and/or it's on its way out.

 

To expand on what lionelhutz said, in this scenario you weren't actually writing to the suspect disk at all.  You were actually writing to the 'virtual/emulated' disk (with very respectable speeds, I might add), which is created from the parity disk and all the data disks.  It doesn't matter if you transferred files to the disk share or to a user share that used that disk, either way you were not actually using the red balled disk.  Your array was running in 'emulated mode', meaning that the data on the red balled disk was being recreated (calculated) on-the-fly by reading every data disk plus your parity disk.  So a write to this emulated disk therefore involves reading all the data disks and the parity disk (but not the red balled disk), then calculating the change in parity, then writing that change to the parity disk.  A similar thing would happen if you read data off the red balled disk.

I've seen the disks within this server run up to 46C, though it isn't on 24/7 (In fact it only runs about 12 hours a week for the scheduled backup) but I've read on this forum that this particular isn't considered at dangerous as running dsisk at +50C or even 60C. Finally I'm running unRAID 4.5.1. Any suggestions? Cheers.

Although I've seen manufacturer's spec sheets stating the temperature limits of disks, there is no way I'd ever suggest you use the array knowing you have disk temperatures consistently at 50C or higher.    You are just asking for problems.  It is even WORSE if the temperature cycles between a much lower temperature (ambient when the server is off) to a blistering hot temperature when it is on for 12 hours.

 

Fix the air-flow to be across the drives.  Add more fans.  They are inexpensive compared to your time data, and sanity.

 

Oh yes, by now I hope you have pressed "Start" and re-constructed the failed disk after performing the un-assign/re-assign steps outlined in the previous post.

  • Author

Hi and thans to all thus far who have posted on this thread. To my dismay (er, re-pharse, my horror), my main unraid server has also a single disk 'disk8' showing the same thing, a red ball! I can read the data off it, which is better than having a completely failed disk I guess.

I noticed something not right as when I was writing data onto the array this afternoon. All disk LED's for the disk enclosures were illuminating while copying files onto it, which I thought, what the ...? But when I examined the web interface, 'disk8' had a red ball. I've had an ongoing issue with either 'disk7' or 'disk8' as either on of the disk marked as 'not installed', and re-jigging the SATA cable resolved the issue. I'd also had my monthly parity check come with 2 parity errors, too which I re-ran the chack, finding 0 errors on the second scan.

I blame either the cheap Silicon Image Si3214 card or some poorly made SATA cabling. To rule out the cabling again, I changed the suspected 'dodgy' cabe along with 5 others, and split the original 12 bunched SATA cabling into 2 lots of 6. I fired up the raid array and again, disk8 had a red ball still. I also tried to un-slot and re-slot the disk back into the enclosure, to no avail. Now, I've just unassigned 'disk8', started the array, stopped the array, re-assigned 'disk8' and it is now doing a 'Data-Rebuild' task. I'm hoping that is fixes this. I'll keep you all updated tomorrow. Cheers.

 

Just to point out the obvious. unRAID is written to protect against a disk failure. When a disk fails, you will still have access to the data that was on that disk and you can still "virtually" write to that disk. The parity disk and the other data disks are used to contruct the disk1 contents you are trying to access on the fly. You now do not have any protection against another disk failing. The red ball means the disk has failed an attempt to write to it and unRAID has taken it out of service. You need to get the red ball corrected before you experience another failure and lose data.

 

 

Your SMART data seems OK so best now to stop array, unassign disk1, start array, stop array, re-assign disk1. Then go back to the main tab and check the "are you sure" box and start the array again. Allow unRAID to attempt to rebuild the disk. See what happens. If it begins to work correctly then it seems you had a cable or connection problem.

 

Peter

 

Hi and thans to all thus far who have posted on this thread. To my dismay (er, re-pharse, my horror), my main unraid server has also a single disk 'disk8' showing the same thing, a red ball! I can read the data off it, which is better than having a completely failed disk I guess.

I noticed something not right as when I was writing data onto the array this afternoon. All disk LED's for the disk enclosures were illuminating while copying files onto it, which I thought, what the ...? But when I examined the web interface, 'disk8' had a red ball. I've had an ongoing issue with either 'disk7' or 'disk8' as either on of the disk marked as 'not installed', and re-jigging the SATA cable resolved the issue. I'd also had my monthly parity check come with 2 parity errors, too which I re-ran the chack, finding 0 errors on the second scan.

I blame either the cheap Silicon Image Si3214 card or some poorly made SATA cabling. To rule out the cabling again, I changed the suspected 'dodgy' cabe along with 5 others, and split the original 12 bunched SATA cabling into 2 lots of 6. I fired up the raid array and again, disk8 had a red ball still. I also tried to un-slot and re-slot the disk back into the enclosure, to no avail. Now, I've just unassigned 'disk8', started the array, stopped the array, re-assigned 'disk8' and it is now doing a 'Data-Rebuild' task. I'm hoping that is fixes this. I'll keep you all updated tomorrow. Cheers.

 

Just to point out the obvious. unRAID is written to protect against a disk failure. When a disk fails, you will still have access to the data that was on that disk and you can still "virtually" write to that disk. The parity disk and the other data disks are used to contruct the disk1 contents you are trying to access on the fly. You now do not have any protection against another disk failing. The red ball means the disk has failed an attempt to write to it and unRAID has taken it out of service. You need to get the red ball corrected before you experience another failure and lose data.

 

 

Your SMART data seems OK so best now to stop array, unassign disk1, start array, stop array, re-assign disk1. Then go back to the main tab and check the "are you sure" box and start the array again. Allow unRAID to attempt to rebuild the disk. See what happens. If it begins to work correctly then it seems you had a cable or connection problem.

 

Peter

 

Once ANY disk is removed from service because a "write" to it failed (and shows as a "red" indicator) it will never be restored to service unless you un-assign it, start the array without it, then stop the array and re-assign it.    This is regardless of the reason.

 

Example, you find a disk "red" and open the case to find the SATA cable completely disconnected.  You breath a sigh of relief, stop the array, power down and then plug in the cable that was disconnected.

 

You power up and the the disk will still show as "red"    Once a disk has failed, it will NEVER come back online simply by re-seating it, or re-seating a connector, or replacing a bad cable, because the array will see it as the same disk that failed. (It remembers the model/serial number) It does not trust the drive. It wants to see a replacement drive installed.

 

To get it to forget the existing disk's model/serial number you must stop the array, un-assign the drive on the devices page, start the array with it un-assigned (this causes it to forget the model/serial number) then, stop the array once more and re-assign the drive.

 

When you next Start the array it will think the drive is a replacement and re-construct the old contents onto it. 

 

Joe L.

...

my main unraid server has also a single disk 'disk8' showing the same thing, a red ball! I can read the data off it, which is better than having a completely failed disk I guess.

...

I noticed something not right as when I was writing data onto the array this afternoon. All disk LED's for the disk enclosures were illuminating while copying files onto

...

 

Your seeing the parity disk at work here.

 

You can "read the data off it" because the parity drive together with all other disks are being used to dynamically reconstruct the miss disk data.

 

 

  • Author

Yeah, true to that. It is better to have all drives 'working together', so to speak to keep the array working, but a risky array at that until the suspected disk is fixed/rebuilt from parity. I've got both my unraid rigs burning the midnight oil (or kw/h that is :) ) and both are re-building their 'signle' failed disks from parity. Fingers crossed on both my rigs. I'll keep you all updated soon. Cheers.

 

...

my main unraid server has also a single disk 'disk8' showing the same thing, a red ball! I can read the data off it, which is better than having a completely failed disk I guess.

...

I noticed something not right as when I was writing data onto the array this afternoon. All disk LED's for the disk enclosures were illuminating while copying files onto

...

 

Your seeing the parity disk at work here.

 

You can "read the data off it" because the parity drive together with all other disks are being used to dynamically reconstruct the miss disk data.

 

 

  • Author

Good news, both my main and my backup unraid server re-synced the single 'suspect' disks and are appearing as healthy. Thanks for the advice (its been a while since I've last touched on trouble shooting :) ). On the note of temps and air flow, on my main rig, it isn't a problem, where the disks get no hotter then 43C for a maximum of 1 to 2 hours, where as my backup unraid server, it is a HP Compaq DC7100 SFF PC, really only designed to hold no more then 2 SATA disks, where I've squeezed a third disk (In the CDROM bay). It runs for 12 hour stints and the temps can reach (from what I've recorded) about 43C to sometimes 46C. I might buy a Shuttle shoe box-style case, get a 2 -> 3 3.5" SATAII disk enclosure bay and build a new backup  unraid server. This should provide better air flow for a small foot print too. Cheers.

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.