Not ps related the test for the ps were done with all drives installed. To further drive that home I was trying to spin that drive and that drive only up and down from unmenu and it would crash every time with all other drives being spun down. All of the other drives would do that fine.

Ah, alright. I must have misread the post then, as I thought it was crashing when doing spin-down all / spin-up all. I didn't catch you were doing things one at a time. My mistake.

I'm just glad everyone is helping. I'm currently upgrading to 4.7 upon that I had to rebuild because of hpa on one of my drives. 200 min to go then I'm going to do the new preclear from joe l on the suspect drive and see what it comes up with.

4.7 installed, new preclear added, hpa removed from one drive all is back up and parity ck said good. currently running preclear on the 2tb drive. going to add it to the array tomorrow if you guys say the results a good from the preclear. now I'm off to stream some ncis for a few hours.

UPDATE::: that drive crashed the server on the preclear

 

SAMBA is STOPPED, Shared drives will not be visible on the LAN. is what I've got now so not a full crash. my syslog was getting full of all kinds of stuff related to that drive.

Had to do a reboot it was taking forever to write the syslog with all the errors. that is probably what took it down. What direction should I go now to isolate this drive?

So after the preclear.sh failed. I tried the normal route of installing a new drive. That was successful although there appeared to be some errors in the syslog, the drive is currently formatting. We'll see what I got when I get home.

The reason you run preclear is to make sure the drive is working well before adding it to your array.

 

Why would you proceed to add a disk to your server if the preclear did not succeed?

I completely hear what your saying, but riddle me this why did it fail with pre clear but not with un raid one of these solutions are not as they should be. If unraid allowed it shouldn't it be good? If not maybe there is a flaw. Not everyone uses joes pre clear script. Un raid does not come with it, but should be doing supposedly doing the same thing.

I completely hear what your saying, but riddle me this why did it fail with pre clear but not with un raid one of these solutions are not as they should be. If unraid allowed it shouldn't it be good? If not maybe there is a flaw. Not everyone uses joes pre clear script. Un raid does not come with it, but should be doing supposedly doing the same thing.

 

Okay, I'll bite. If I understand your question correctly, why doesn't unRAID exercise the drive prior to adding it to your array to assure you that it is good? Well only Tom can answer that question with the real answer, but I'll give you my opinion. It is beyond the scope of the product.

 

Disk drives are going down in quality. It is much more likely to experience an infant mortality than it used to be (from my observations). So who picks up the slack for this problem? The user, many utilities are out there to exercise a drive to assure it is working well before you trust your data. It is prudent to do that whatever it is to be used for. Exercise it before installing windows, before installing it in a RAID array or before using it in unRAID.

Sure will be nice to see if unraid finds this drive to be bad, if not why are we running un raid.

Sure will be nice to see if unraid finds this drive to be bad, if not why are we running un raid.

 

unRAID isn't designed or used to test hard drives.

unRAID will protect you from a failed disk. In order to lessen the odds that two disks will fail before a hard disk is replaced, many users do the following:

 

Run regular parity checks - this verifies correct operation of the parity and will help identify a problem with a disk before you have total failure. I run a parity verify once a month.

 

Run regular smart checks of all disks - using bjp999's excellent mymain, a smart check all your disks is just one click. I run this about once a week.

 

Have an exercised disk to use as a spare on hand.

 

The few times that I have seen users loose data because of failed disks it usually because they had a disk that was degrading without their knowledge and then another disk failed. Since they were not monitoring the health of their array, when it came time to rebuild the failed disk the marginal disk could not provide the necessary information for the failed disk to be rebuilt.

I completely hear what your saying, but riddle me this why did it fail with pre clear but not with un raid one of these solutions are not as they should be. If unraid allowed it shouldn't it be good? If not maybe there is a flaw. Not everyone uses joes pre clear script. Un raid does not come with it, but should be doing supposedly doing the same thing.

The process unRAID uses, when adding a new disk, is to writes zeros to the entire drive.  It does this blindly, not reading what is written.    It trusts they are written properly.  It trusts all the sectors on the disk will be readable. 

 

The unRAID software will eventually read all the bytes it wrote when you next perform a manual full parity check.  At that point you'll first learn of a disk that could not be written properly.  You will see parity errors... You'll NOT know which disk is in error though, only that one of the bits on one of the disks was in error.  unRAID always assumes the parity disk is wrong and corrects it.  That might not be the right action.  (Also, it might be weeks or months later when the "write" error is detected, since the parity check is not done until you perform it or the array is not stopped cleanly in a power failure.)

 

Worse would be if another disk were to fail before you run a manual parity check.  Then the first time you attempt to read the newly added disks are in the attempt to re-construct the failed drive.  Any read failure then will result in lost data.

 

I know you had a bad experience and that the preclear script filled all your memory with the error log.  If anything, that suggests I might be able to add a test to the preclear script to have it terminate the preclear_script if it detects the syslog is growing at a rapid rate.

 

Joe L.

Well I didn't really think of it as a bad experience, but took it as just the way it is. I'm going to continue to use preclear. I like not having to take the array down to clear. I really would like to narrow down the problem with this drive. Best option for me now from what I'm gathering is just get a new drive, and see if I still have problems. I'm betting I won't just would like to know this drive is bad before I RMA.

Just ordered a WD20EARS 2tb.

That suspect drive is now added to the array and the array spins up and down without a hitch now I've done it about 20 times in a row. What smart test is recommended. Also how many of you had a 2tb drive assigned as the cache? Just trying to narrow down possible issues. And I know I didn't need that as a cache but put it there until I needed to expand the array.

I don't personally do it, but I've set up a few client builds with 2 TB drives as cache drives (so that they double as a warm spare).  I've seen no issues doing this.

 

I guess I recommend the long SMART test?  Not sure I understand the question.

Long smart tests have started. I will post the results

That suspect drive is now added to the array and the array spins up and down without a hitch now I've done it about 20 times in a row. What smart test is recommended. Also how many of you had a 2tb drive assigned as the cache? Just trying to narrow down possible issues. And I know I didn't need that as a cache but put it there until I needed to expand the array.

Spinning the disk up and down means nothing.

 

When unRAID (or any OS) writes to a drive, it assumes the drive is good.  So suppose for a second that a part of the disk is damaged.  The computer can issue a command to write data there, and the drive will respond like it did.  Problem is, the data didn't take hold because the spot on the disk was bad.  If you try to read it you will get errors.  But if you never read it, you'd never know.

 

Preclear works by reading, then writing, then reading every sector on the disk.  The reading after the writing is particularly important.  Becuase the second read cycle makes sure that the write cycle worked.  This is a great test for a drive.

 

unRAID does not do this.  It only does the write cycle.  If the writes don't work 100%, you wouldn't know.

 

You asked why you should care.  unRAID protects you against a disk loss.  No big deal.

 

Problem is - if a disk really does fail - EVERY sector on EVERY other disk has got to be perfect to recover the disk.  People mistakenly think that it is the parity that recovers the failed disk.  it is not.  It is every other disk except the failed one, working together, that allows the disk to be recovered.  So if you have 10 disks, and 1 fails, the other 9 have to be perfect.  If you start adding disks to your array without confidence that they are good, you will quickly find that a disk has failed, and then go to rebuild it. But guess what - you'll have no idea whether it built it correctly or not, becuase you won't know if you can trust the other disks.  And that's if you don't get a gazillion errors filling your syslog.

 

If you ran preclear and it filled your syslog with errors, one of a number of things could be wrong.  Most likley a cable is bad or marginal.  This is very common.  If a cable is bad the drive can work for hours, days or longer, and then suddently the drive loses power or data connection and the OS goes crazy with errors.  If you try to put in a replacement disk, using the same bad cable, you will start getting errors on the new disk.  Recovering your data without fixing the cable will be hopeless.  This is why you can't ignore the errors.  You have to know you can trust the motherboad, controllers, ports, cables, and drives - because they all have to be working 100% reliable for unRAID to be able to do its job.  unRAID can recover a single failed disk from an otheriwse 100% healthy array.

 

I don't understand the current state of your array, but if you have added a bunch of disks without running tests on them and are hoping for the best, you can't trust that your array is solid.  You need to run a full parity check.  If it comes up clean you have to run a smart report on each disk.  If that comes up clean you are lucky (and in good shape).  But if you are getting syslog errors during the parity check, or reallocated sectors in your smart reports, your array is not healthy and you need to fix it to get the benefits of unRAID.

Your right it means nothing. Not being able to do it before and being able to do it now does.

Parity check good no reported errors. I started long smart tests on 5 drives at 0600. Well see what it shows when I get home. What is the best method for retrieving the results of the test in the most simple form?

All of the long smart tests that were done today say at the bottom....SMART Self-test log structure revision number 1

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error

# 1  Extended offline    Completed without error      00%      2727        -

Is there anything else I need to pay particular attention to? How bout anything else in addition to these tests?

How do the attribute fields look in the SMART report? Are any FAILING_NOW or are any NOMINAL values near the THRESHOLD values?

Give me your opinion please.

smart.txt