Joe L.

Even though it looks like you responded with "Yes", is it possible you added a leading or trailing space (or some non-printing character) when you typed "Yes" Are you using a non-standard keyboard? or a different language character set? The code looking for the "Yes" response has been there forever. Joe L.

It might work, if cache_dirs was in a directory already in your search PATH. It would be better if you put the full path to cache_dirs, like this as an example: #define USER_SCRIPT_LABEL Stop cache_dirs #define USER_SCRIPT_DESCR Stop the cache_dir script # # stop cache_dir /boot/cache_dirs -q Before you go crazy, cache_dirs already monitors the syslog and can detect when the array is being stopped. When this occurs, it suspends itself. It does not prevent the array from stopping. If you do not reboot, but start the array again, it re-starts itself.. Joe L.

They look good. I think 12 concurrent clear processes is a new record. It did keep the server plenty busy, so I'm sure it was a good burn-in test of the disks, disk controllers, and motherboard. I think the same. I was only worried about not to watch the Pre-clear screen again ("screen - r" didn't work; next time I'll name my screens to find them back in an easier way as the user secrectagent suggested me), but I received an email when each HDD had finishied and could save my results too. The results are also saved in a preclear_reports directory on your flash drive.

They look good. I think 12 concurrent clear processes is a new record. It did keep the server plenty busy, so I'm sure it was a good burn-in test of the disks, disk controllers, and motherboard.

You can pre-clear as many disks as you like at a time (as long as you have ports on the disk controllers to connect them to and enough memory to run all the processes). It has nothing to do with the unRAID license. The license just determines how many disks you can assign to the protected array on the unRAID management screen and if some of the security and cache drive features are available. You can always have as many disks as you desire outside of the protected array.

The disks all passed the pre-clear. No sectors were re-allocated. Nothing looks unusual. 1 cycle is far better than none. Too many disks failing in the initial pre-clear for my comfort. Many prefer to run several more cycles if they do not need to put the disks into service immediately. Joe L.

How many times must this be said. The "raw" values are meaningful to the manufacturers. The one disk seems to initialize most of their values to 100, the other to 200. The seek-time initialized value is still the current value and is nowhere near the failure threshold.

No.

better than that. If a drive fails it is re-constructed and simulated for both reading and writing. If you do not look at the array status, you may not notice that a drive has failed (other than all the drives will be spinning) I've personally played 4 different ISO DVD images to 4 different media players on my LAN from a "failed" disk. (I simulated a failure to perform the tests) When you install a replacement, the re-constructed contents, with any changes included, are written to the replacement drive. You do NOT temporarily lose any contents if a single drive fails. Joe L.

config fields can be added, but unMENU only has one config field type.. a simple input field. unMENU's package manager does not have drop-down lists, or browseable input fields... at least not at this time. Since it it written in"awk" they could be added... if he was inclined... and I'd be happy to include the improvements in unMENU's official release, but for now, simple input fields will have to do. Joe L.

You don't even need to re-start unMENU, just refresh the Pkg Manager page in your browser (or open that page if not currently open) after putting the .conf files in either the /boot/unmenu directory or the /boot/packages directory.

Don't bundle power cables with SATA data cables. (it can sometimes cause weird induced noise on the SATA cables causing difficult to find random disk errors.)

One of the major reasons the preclear script has changed and new versions released, is to try to make questions like yours go away. Please ALWAYS download and use the latest version before pre-clearing a disk. If you are going to invest 26+ hours in testing a disk, you might as well take advantage of the newest version of the output report. What version of preclear_disk.sh are you using? You can type preclear_disk.sh -v to find out. Oh yes, your disk looks fine, however, that is an EARS drive. It might need a jumper added to it for best performance. What version of unRAID are you running? Did you install a jumper on the drive before clearing it? Joe L.

Other than a moderately high load-cycle-count, but probably not too high given its run-time hours, I see nothing at all wrong with that drive. What makes you want to RMA it? There are no re-allocated sectors, and none pending re-allocation. What attribute concerns you? Joe L. I guess I was looking Raw_Read_Error_Rate, Offline_uncorrectable and the Multi_Zone_Error_Rate. All the rest of my drives have zero for those attributes. So you think this drive is okay then? Thanks Joe. Some drives show raw values, others do not, and MOST are completely meaningless to end-users. If the normalized value is above the affiliated failure threshold the drive does not FAIL the smart test for that attribute. In EVERY attribute you mentioned the VALUE is the original 200 that was set from the factory. They've not changed at all. There is nothing wrong with that drive.

Other than a moderately high load-cycle-count, but probably not too high given its run-time hours, I see nothing at all wrong with that drive. What makes you want to RMA it? There are no re-allocated sectors, and none pending re-allocation. What attribute concerns you? Joe L.

I don't see anything glaring in the smartctl report. You need to look in the system log for errors. You need to look at what else your server was doing in the same time-frame. It is not that far outside of the norm. It could be your system was just busy. (or I/O was bottlenecked on your disk controller, or your disk controller is set to an IDE emulation mode/Legacy compatibility mode instead of AHCI mode which will slow it down) I do not see a reason to RMA the drive.

It indicates that three of the blocks read back DID NOT have all zeros as expected. This is the type of situation that causes hair loss (and parity checks that occasionally/constantly return parity errors) The cause can be a bad drive (we've seen this several times with other users) or a bad disk controller (also seen several times) or a bad power supply (power supply noise caused the writes to not function properly) or temperature (disks got too hot and were unable to read their own tracks because of thermal expansion) or vibration (disks shaking made them unable to write accurately) or even the motherboard chipset (nforce4 chipsets on early motherboards were prone to this) It cold also be your RAM, if it is not configured properly in your BIOS with the correct voltage, clock speed, and timing. (run a memtest overnight to eliminate it as a suspect) Good luck in isolating the issue. I'd not use that drive in that server connected/configured as it current is until you can get through several more pre-clear cycles with NO errors. Unfortunately, this class of error is frequently not detectable by any other test other than reading the contents of the disk. You might be lucky and see actual errors in the system log, but there are odds you will not see any error in the syslog and no errors in the smart report. I know, it is not good news... but I would not trust a server where the data I wrote was not readable accurately, even if it was only four times during the post-read. This class of error is EXACTLY why I added the post-read verify to the pre-clear script. Prior to it being added, there was no way to learn of the bad disk/controller/??? until AFTER it was in the array and you had stored data on it and subsequently dis a parity check. By then, it is MUCH harder to figure out which disk is causing the intermittent parity errors. Joe L.

thing is, most of the market wont do any kind of testing. unraid is a small niche of people who will do that but most common people wont test the hard drive. most shops that will sell you a custom pc wont do any testing either. Also, fixing the drives might cost but, in the long run, replacing them could cost more (although i guess they estimate that). You're probably right. So the OEMs are really focused on making sure the drives is not DOA and also making sure it has enough spare sectors available so that the drive won't fail until it gets out of warranty. I doubt if the drives get anything more than a brief physical and electrical test at the factory. It simply would take too long otherwise. I cannot imagine them taking 4 or 5 hours per drive to run them even through an internal "long" smart test. As you said, the cost of the warranty returns is built into the initial price of the drive. Most people will never know how poorly their drives are performing in their PCs. They'll just blame it all on buggy operating systems and programs. Joe L.

Just for kicks I tried another pre-clear on the new disk that had failed SMART with thousands of re-allocated sectors in its first few hours of use. This time I got this in the syslog (the last line is very interesting): Mar 12 06:10:31 Tower2 kernel: end_request: I/O error, dev sdf, sector 0 (Errors) Mar 12 06:10:31 Tower2 kernel: sd 4:0:0:0: [sdf] Unhandled error code (Errors) Mar 12 06:10:31 Tower2 kernel: sd 4:0:0:0: [sdf] Result: hostbyte=0x04 driverbyte=0x00 (System) Mar 12 06:10:31 Tower2 kernel: sd 4:0:0:0: [sdf] CDB: cdb[0]=0x28: 28 00 00 00 00 00 00 00 08 00 (Drive related) Mar 12 06:10:31 Tower2 kernel: end_request: I/O error, dev sdf, sector 0 (Errors) Mar 12 06:10:31 Tower2 kernel: sd 4:0:0:0: [sdf] Unhandled error code (Errors) Mar 12 06:10:31 Tower2 kernel: sd 4:0:0:0: [sdf] Result: hostbyte=0x04 driverbyte=0x00 (System) Mar 12 06:10:31 Tower2 kernel: sd 4:0:0:0: [sdf] CDB: cdb[0]=0x28: 28 00 00 00 10 00 00 00 08 00 (Drive related) Mar 12 06:10:31 Tower2 kernel: end_request: I/O error, dev sdf, sector 4096 (Errors) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] READ CAPACITY(16) failed (Drive related) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] Result: hostbyte=0x04 driverbyte=0x00 (System) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] Sense not available. (Drive related) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] READ CAPACITY failed (Drive related) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] Result: hostbyte=0x04 driverbyte=0x00 (System) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] Sense not available. (Drive related) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] Asking for cache data failed (Drive related) Mar 12 06:10:36 Tower2 kernel: sd 4:0:0:0: [sdf] Assuming drive cache: write through (Drive related) Mar 12 06:10:36 Tower2 kernel: sdf: detected capacity change from 2000398934016 to 0 (Drive related) It was /dev/sdf. Now it does not even show up in a listing of /dev. It just died... completely. It was not kidding when it said the capacity is now zero. I guess an RMA is in order. Joe L.

older releases of inRAID would show an un-mounted drive as un-formatted. The option is not as important as in the past.

Yes, I know it only stores one report per drive, per day. You can go back in the system log if you really want to look at the others. For the most part, the latest is all you really care about. As far as those attributes "near-threshold" I print that when the value is within 25 of the affiliated failure threshold. It looks like the initial value of "100" on those few attributes is only within a few of the failure threshold of 97. It just indicates the manufacturer has very little granularity in their normalization of those few attributed. As far as Hardware_ECC_Recovered coming and going, it just indicates the NEW_VAL sometimes does not change. If you look more closely, you'll see the NEW_VAL has moved FURTHER from the failure threshold in both cases. That is not an indication of a problem, but perhaps of a drive working better as it gets some wear on it and bearing, etc get broken in. Joe L.

Short answer, probably not.

Actually, that drive shows 5 Reallocated_Sector_Ct 0x0033 149 149 140 Pre-fail Always - 403 and 197 Current_Pending_Sector 0x0032 198 197 000 Old_age Always - 939 There are 403 sectors already re-allocated, and another 939 that are pending re-allocation. In other words, it needs to be replaced... soon, as it is failing. the normalized VALUE is nearing the failure threshold. Even though the failure threshold has not yet been reached, the drive is dying. RMA it. (sorry, I missed those lines the first time I looked at your post. It is NOT a healthy drive.)

Those are attribute classes. Some attributes are used to track usage, other to attempt to predict failure. Every attribute belongs to one of those two classes.

The RAW values have meaning ONLY to the manufacturer. Only a few represent actual counts we can interpret. As an example, the "head flying hours" on your first disk has a raw value of 234552459001957 Now, even if not "hours" but seconds, it would indicate the drive was 446,246,575 years old. Now, it might be... but it is very unlikely. There is NO standard for the raw values. You can only compare the NORMALIZED "VALUE" to its affiliated failure "THRESHOLD" If higher than the threshold, the parameter is NOT failing. All your disks are perfectly fine. The "big" numbers are meaningless.