I just got a red ball on one of my drives while copying files to it (it has 2000+ errors). I attempted to run a smartctl report via the following command from the troubleshooting page: smartctl  -a  -d  ata  /dev/sdf >/boot/smart.txt (sdf is my drive). The report is blank. When I attempt to run it via the smartctl  -a  -d  ata  /dev/sdf command, I get a message that says "A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options."

 

The syslog is over a GB ... is this really accurate? And, I have no idea how to open it.

 

I have spent the last hour searching this forum for answers, but have gotten nowhere. I have been copying files from the "failed" drive to another hard drive. Will these files be corrupted?

 

Any help would be greatly appreciated.

 

Thanks much.

I just got a red ball on one of my drives while copying files to it (it has 2000+ errors). I attempted to run a smartctl report via the following command from the troubleshooting page: smartctl  -a  -d  ata  /dev/sdf >/boot/smart.txt (sdf is my drive). The report is blank. When I attempt to run it via the smartctl  -a  -d  ata  /dev/sdf command, I get a message that says "A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options."

 

The syslog is over a GB ... is this really accurate? And, I have no idea how to open it.

 

I have spent the last hour searching this forum for answers, but have gotten nowhere. I have been copying files from the "failed" drive to another hard drive. Will these files be corrupted?

 

Any help would be greatly appreciated.

 

Thanks much.

The "red" indicator basically says that a "write" to the drive faile.  It was therefore disabled.  Any reading and writing of files to that disabled are now being written to the "simulated reconstructed drive" made possible by parity and the other data drives.  The files you've copied to the "failed" drive will be perfectly fine, as long as all the other drives in your server are OK.  Basically you are seeing the "RAID" array at work.    You are not protected against a second concurrent drive failure right now.  If a second drive were to fail you will lose the contents of both failed drives.  For that reason it is important to fix/replace the failed drive as soon as possible.

 

You've attempted a smart report. It too cannot communicate with the drive.    That would indicate that EITHER the drive itself has failed, or the data or power cable to the drive has come loose.

 

What you need to do now is to first capture a syslog.  It might have clues that will help determine how it failed.  Since it is huge, try this to get the first 10000 lines of it.

sed 10000q /var/log/syslog >/boot/syslog.txt

Then stop the array, power down, re-seat the cables to the failed drive (including the end of the data cable at the disk controller) and then power up and see if you can get a smart report to complete.  If you can, the odds are it was just a bad connection.  If a smart report is available it it s good first step.

 

If no smart report is available, even after re-seating the connectors, the drive has probably failed.  You could try an alternate cable to the drive, just in case. (again power down before changing cables and do not disturb other cables in the server, otherwise you might end up with two failed drives and a more complicated restore effort.)

 

If the smart report works then...

Stop the array

Un-assign the failed drive on the devices page

Start the array with it un-assigned

Stop the array once more

Re-Assign the failed drive to its slot in the srray

Start the array once more.  The contents of the failed drive and all the files you've written to it since it had failed will be re-constructed onto the drive.  once the re-construction is complete the array will be protected by parity once more.

 

The procedure if the drive actually failed is nearly the same.

Stop the array

Power down

Replace the drive with a new drive of equal or greater size but not larger than your parity drive.

Power up.

The server will notice the new drive and should say something about re-construction the failed drive's contents onto the replacement.

Check the box under "Start" and press "Start"

As long as you used the same port on the disk controller there will be no need to use the "Devices" page to assign the new replacement disk.

 

Joe L.

Joe,

Thanks millions for your detailed explanation - and your time. As a non-Linux novice, I was feeling a bit lonely and bewildered when I got that red ball. I'll give your suggestions a try and let you know what the results are as soon as my backup of the "failed" drive is complete.

I just tried capturing the first 10000 lines of the syslog, utilizing your command, but got the message: "sed: couldn't write 95 items to stdout: No space left on device". I went to the view the contents of the flash drive via Windows Explorer and found that the syslog is 1.7 GBs. Shortly after I got the red ball, I did manage to copy the entire syslog from my flash drive onto my other server (ironically, WHS - the server that I'm attempting to move away from). At the time (8 hrs ago), the syslog was "only" 1 GB.

 

-How can I open/read this copied syslog (of course, I'm assuming that even if I could open it, that I'd understand any of it - which is probably a pipe-dream)?

-Can I copy a portion of this copied syslog so that I can post it?

-Is there a way to make the final destination for this mini-syslog the "c" drive of my Windows computer?

-What happens now that there appears to be no more space on my flash drive (UnRaid boot drive) ... does UnRaid automatically purge the bloat of the syslog? (As an aside, this is the same flash drive that I got from Tom when I purchased UnRaid.)

-If I need to replace my drive, do I need to preclear the new one or can I merely stick the drive in its place (the drive will probably be one that I have taken from my WHS so it will have some old data on it in the NTFS/WHS format).

 

Thanks.

not sure about directly to your c: drive but could put it to one of the unraid disks.

 

sed 10000q /var/log/syslog >/var/log/syslog.txt

 

or just change the /boot/ to /path-you-want/ then you could copy over to c drive if needed.

 

check if you have /boot/syslog.txt  ... you could delete that to free up space

 

 

not sure about directly to your c: drive but could put it to one of the unraid disks.

 

sed 10000q /var/log/syslog >/var/log/syslog.txt

That will probably work.

 

or just change the /boot/ to /path-you-want/ then you could copy over to c drive if needed.

Yes you could change it to copy to a directory you have on a data disk by typing

sed 10000q /var/log/syslog >"/mnt/disk1/YourShareName/syslog.txt"

 

Just make sure you use a share name that exists on disk1.

check if you have /boot/syslog.txt  ... you could delete that to free up space

Also true.  It is probably using all the free space on the flash drive.  Remove it by typing:

rm /boot/syslog.txt

 

Joe L.

Follow-up: I followed your instructions and am back in business. I ran the smartctl command and got no errors. I'm not sure if disconnecting/reconnecting the cables was the problem - at the time that I got the red ball the server was getting some fairly heavy use with several copies, etc. Nonetheless, it is working now.

 

Again, Joe and Graywolf, your time and detailed suggestions/solutions are greatly appreciated.

 

Many, many thanks ...