RobJ

In your BIOS setup, make sure that both the onboard and addon SATA controllers are configured for native SATA mode, preferably AHCI mode, *NOT* in an IDE emulation mode. Having drive symbols appear as hdx usually means they are IDE drives or configured to emulate IDE drives.

I'll start by saying that all 3 drives look fine, no issues at all. For the following, ignore the temperature SMART attributes (190 and 194), they have their own interpretation rules. For the rest, you should not look at the Raw numbers for most SMART attributes, just the VALUE column (and perhaps the WORST column), which are an attempt by the manufacturer to indicate its own valuation of the numbers. Generally the VALUE's will be from 1 to 100, but often they may be from 1 to 200, or even for a few Maxtors 1 to 253 (the 200's can be halved and considered as 100's). That means you can generally think of them as percentages of perfect, as in 100 is considered factory perfect and 1 is bottomed-out bad and 50 is probably not very good. So even though a Raw_Read_Error_Rate may have a very high raw number, if its VALUE is 100, then the drive manufacturer considers its read error rate to be perfectly normal. I think we look too fast at the raw numbers, most of them should be ignored. We should look first at all the 100's and/or 200's in the VALUE and WORST columns. As to a possible cable issue, I see no evidence of that. Would need the corresponding syslog to know for sure. From here on, I'm moving from factual to speculative, trying to come up with ideas why one drive performed somewhat slower, even though all 3 drives were identical, and had the same firmware version. The most likely reason is that different controller chipsets or busses were involved, and the slow drive was stuck with the slower hardware, was bullied out of a fair share of the I/O bandwidth available. You could verify this by swapping its connection with one of the fast drives, and retesting. But since we're already speculating ... we'll drift a little farther out in left field. All 3 SMART reports were essentially identical, as would be expected by identical drives. But there were 2 odd differences, one was that the slow drive had a far higher SEEK_ERROR_RATE raw number (which we should normally ignore!), and the other was that the slow drive reported a much longer time needed for offline data collection, a fact that is really strange for identical drives! The fast drives sda and sdc reported they only need 80 seconds for offline data collection. The slow drive sdd reports it needs 139 seconds! I don't want to put too much importance on that, since the manufacturers do not provide any info on properly interpreting these numbers, but it does seem very odd, and perhaps indicative of a slower drive. And while I really don't want to draw any conclusions from the SEEK_ERROR_RATE raw number, it plausibly *may* represent the need for many more seeks than the other drives, and seeks are relatively slow actions. You might want to run a drive speed testing tool (HDTune?) on both the slow drive and a fast drive, and compare. Now for some crazy speculation... Manufacturers like to cut corners. What if, to make 1TB, 2TB, 3TB, and 4TB drives, they just set up production lines for 4TB platter sets, and then when factory testing them, sell the partially defective ones as smaller drives. So if one cannot support 4TB, determine how much it CAN support and sell it accordingly. Now, what if a platter set had a bad region only in the faster tracks, but had 3TB available in the slower tracks? You would create a good 3TB drive, but it would be significantly slower than the average 3TB drive. No easy way to know for sure...

SMART attribute 4, Start_Stop_Count, is not a critical attribute, so does not count as part of the SMART pass/fail testing. You can tell which are critical attributes by the Type column of the SMART report, Pre-fail indicates a critical item, Old_age just indicates other non-critical items. It looks to me as if the Threshhold for Start_Stop_Count should be 000 just like Load_Cycle_Count, which has also bottomed out. These just indicate you have a lot of wear on this drive. It appears the Power_On_Hours value is corrupted, perhaps also due to old age. All other numbers look great, you should still have considerable life left in this drive. By the way, this drive is a 160GB Seagate Momentus ST9160823AS drive, it is not an SSD.

The final SMART report looks clean, but indicates it has had some questionable sectors, just as the Preclear report indicated, when it said that Current_Pending_Sector count rose from 2 to 9, then ended up cleared. The fact that all questionable sectors were cleared for further use seems to indicate that the drive's media surface is OK, but there was some event that scrambled the data in a few sectors, perhaps an electrical spike or sudden power outage while writing to the drive. SMART actually says there have been 319 ATA errors, but only shows the last one (which is somewhat odd, usually shows the last 5). You mention it may have been a factory reconditioned drive, so perhaps they reset some of the SMART parameters. It *claims* to be a very young drive, with only 205 hours on it. There's no reason to RMA it now, but it does seem a little suspicious. I recommend running one or two more Preclears on it, just to be sure you can trust it.

1. Would very much appreciate, if someone verifies the results, that drives are ok. All 3 drives look great. 2. Whats the preferred method to post the results: via attached files, or in a "code" insert? Attached files is better (as you did). 5. It's been more than 10 hours since I ran preclear, but myMain always shows the drives as spinning. Why haven't they been spun down after an hour of inactivity? Is it because they're unassigned? (see picture below) UnRAID manages spindown only for assigned drives, and you haven't done that yet. You can manually spin them down in the UnMENU interface using the little spin icons for each drive.

I don't know about your Samsung, but this Seagate 2TB drive looks fine. Device Model: ST2000DL004 HD204UI Serial Number: *********2495

Remember that the device symbols (sda, sdg, etc) may change at each boot. Is it possible that the drive was sdg on the previous boot, but not in the current session? Try a 'preclear_disk.sh -l' first, to verify current symbol assignments.

However, that SMART report is enough to say that your drive looks great! That is, if this SMART report is for the same drive that was producing the errors in your previous snippet. I think that what would be most helpful is the entire syslog that that snip came from. Please try to zip and attach it.

I have to agree with Joe, there's not enough info there to tell if there is anything at all wrong with the drive. The snip is especially confusing, because it appears to be missing a lot of lines between the ones showing. It is always best to include the entire syslog. If you don't want to, then the next best is to include that section of the syslog containing the very first errors related to a drive. They are usually the most important.

Your drive is as near perfect as it can be. In fact, it is a perfect example of modern Seagate drives. Seagate is the only one that displays the raw values for raw reads and seeks, and you can ignore them. What is more important is that Raw_Read_Error_Rate has a value of 116, which could be considered better than perfect (100). What is also very typical of Seagates - the Seek_Error_Rate starts and stays in the 60's, and I have no idea why they do that. So long as it does not start dropping towards 30, everything is fine. Enjoy what looks like a great drive!

The drive looks fine, and with only about 8000 hours on it, is relatively young. Nothing to be concerned about in your SMART reports for it. Helmonder: I could not seem to find time to respond before, and Joe's answer is essentially what I would have said, except I'm not as succinct! He noted the one concern I had, about that one sector that popped up. I'll just add the one comment, that sectors marked 'Pending' are not necessarily permanently bad, they may have physically perfect media under them but have been scrambled by a power spike or outage during a past write to them, or some other corrupting event. Once rewritten (the Preclear zeroing), they prove to be fine.

Unless something turns up on the next Preclear report for this drive, the drive should be fine. If you examine the SMART report you attached, you can see that the drive has almost 12000 hours of usage (Power_On_Hours = 11826), and the last UNC error (UNCorrectable media error - data in a sector too scrambled for ECC info to correct) was at 1428 hours, perhaps 2 to 6 months after you acquired the drive and over 10000 usage hours ago. The drive does report 13 UNC errors, which corresponds to the 13 errors in the SMART log. The log only shows the last 5, but you can see that at 1428 hours, 3 UNC errors occurred, 2 of which are repeats of the 2 errors preceding (error #9 and #10). We cannot see errors 1 through 8, but we know that they were UNC errors like the 5 we CAN see, and we know that they occurred no later than hour 53, which is within the first 3 days of drive usage. So you have been using the drive for over 10000 hours without any issues, and that is why I think the drive is fine pending any adverse results from the Preclear of it. The writing of zeroes to the entire drive should make any issues visible. The fact that 2 (at least) sectors have appeared twice (at differing times) to be UNC does seem a little suspicious, so the media surface under them may be a little weak. Ideally (I think), Preclear will force the drive to discover and remap them. That would result in a few Reallocated sectors, but if a subsequent Preclear is clear with no further changes, then the drive should be very good, and you would no longer even have to worry about weak sectors.

Yes, 4 to 6 hours does seem like a significant limiting factor in manufacturing them, but don't they already have to low-level format them? I don't know for sure, but it seems reasonable to me that their formatting machines are testing while writing. I suspect that they are using proprietary machines much faster than our consumer drives, perhaps multi-headed. If I were there, I would want the engineers to design a drive without the common single-headed swing arm, and use something like a sliding bar perpendicular to the tracks, crammed with all the heads that can fit on it, each wired for simultaneous read/write, plus multi-threaded software to simultaneously operate each head, plus a high speed bus to handle all that I/O. If you could cram heads 3mm apart, then the bar only has to slide 3mm in a radial direction for heads to reach every track. That would be about 8 heads per inch, giving you 10 to 15 heads to speed up the formatting, and 6 hours goes down to about half an hour. And if they can double or triple the rotational speed ... Speculating again... Testing could be as simple as reading the track immediately after writing the formatting, before moving to another track. With our consumer drives, that would certainly slow the process down, but if we add a second head bar to our hypothetical machine, so that it reads after the first set of heads write, then there is almost no extra time required. I'm sure they don't need my ideas(!), but I do think they must have much faster machines than we do.

I am tempted to say no... I have spent some time browsing the forums on SMART results, what I have come to understand is that what your drive is doing could possibly be ok, but parts of the drive ARE failing so it comes down to wanting to take a risk... Looking at the prices of disks I would advise taking out this disk, using it for some other kind of storage (its not broken yet) and replace your unraid drive with a fresh one that comes out of multuple preclear cycles without any issues.. I would try another pre-clear cycle. Each cycle so far has uncovered additional un-readable sectors. If that continues, the drive is not one I'd want in my array. On the other hand, I've got one drive with 100 re-allocated sectors that has never changed from the first pre-clear I ran it through. Since it is stable, I trust it. Joe L. This keeps coming up, and I have been thinking about it, and wrote up some thoughts, perhaps for a future SMART wiki page. I don't know if this is an appropriate place for them, so I apologize in advance to Joe L. My thoughts below: (apologies also for the lack of clarity in my writing) I've noticed that users generally feel that a newly acquired drive that does not maintain a perfect SMART report in its first week is worth much less than a drive that remains perfect, SMART-wise. In addition, users often consider any drive with a significant number of remapped sectors to be suspect. To a large extent, that makes sense, and yet I have had doubts as to the significance of a perfect SMART report. [speculative] Sometimes I wonder if the "0 sectors reallocated" is a real zero, or a normalized base line of zero. In other words, are these drives really that perfect, with all tracks and sectors completely contiguous? Or is it possible that they have initialized the starting drive maps so that, after initial testing, they only include sectors that have passed testing? If so, then an initial value of zero bad sectors is not very meaningful, and furthermore, we should probably not be that concerned with a few bad sectors that appear in the first month of a drive's life. It is easy to speculate that what actually happens is more like this: engineering tests determine that a new drive can potentially carry X number of tracks (for illustration we will use the number 5300). Management says they want a drive of size Y, which will require 5000 tracks, plus an extra 100 tracks reserved for spare sectors. So an initialization program is set up to install the firmware, do the basic tests of the drive, and then initialize the starting drive maps by locating the best 5100 tracks of those 5300, and then reserve a hundred for spare sectors. In other words, there could well be a number of tracks skipped, perhaps only because they had a single sector that seemed questionable. How would we know the difference, between this and a pristine totally contiguous drive? We wouldn't! The initial SMART values would be cleared, and appear perfect. From your experience with manufacturers in general, would you not say that monetary and marketing factors are more likely to drive product design than other factors? It does make sense from a practical point of view, so I personally think this is a likely scenario. All of which makes the current value of remapped sectors somewhat meaningless, so long as the number is not changing. [Disclaimer: this is all speculation, I have no inside knowledge, and it is possible that the platters are actually made so well, so consistent (over-engineered?) that they usually ARE near perfect.] And I don't know that this really matters either. I like the current setup, where you acquire an apparently pristine drive, that includes a relatively large number of spares to replace any that suffer 'infant mortality' plus more for the long term loss due to wear and tear or whatever. [/speculative] The important thing therefore may not be to focus too much on the current number of reallocated sectors, zero or otherwise, but on whether the number is growing. A growing number is always concerning, but once our testing appears to show that the number has plateaued (no change at all), then the drive should again regain our confidence. I think an enormous number of drives have been returned, that may have had many reliable years left in them.

At 'Apr 20 03:15:57', the drive stopped responding to commands. A hard reset was sent, and the SATA Link reported no problems, was full speed at 3.0gbps, but there was still no response to higher level queries over that link, not even identity info. After more hard resets with similar results, the SATA link was slowed to 1.5, to see if that might make a difference, but unsuccessful too. So at 'Apr 20 03:16:52', Linux marks the drive device sdh as disabled. Once a device has been marked as disabled, I have never yet seen a recovery, until next boot. And you can completely ignore all of the subsequent error messages and actions related to that drive (including that second section you quoted). It does look like the kernel successfully recovered the drive later, and even read the partition table, but it was too late. It was as a new device sdi, which unRAID and Preclear knew nothing about. After a reboot, everything should have appeared to be fine, except that Preclear had to abort. In my experience, a drive disabled this way is usually not at fault for the trouble. It is generally an issue related to the driver or cable or controller card, or possibly a power issue. So no, this particular problem would not be a reason to RMA the drive. However, the syslog and SMART and Preclear reports you have provided do show an ongoing series of problematic (possibly bad) sectors, media errors. Another Preclear is very necessary, and if it is perfect (no further pending or remapped sectors), then I would recommend an additional Preclear, just to see if it too is clean. I think I would only trust this drive if it can perfectly pass 2 consecutive Preclears. A drive that keeps finding new bad sectors on each pass, that are never the same, seems very suspicious to me.

To powerchoke and khuong (and any others worried about these 'near_thresh' alerts) - you can safely ignore them. Joe very helpfully simplified the SMART reports and their before/after attribute changes, and added the 'near_thresh' alert to help users note any attributes that appeared to be degrading, approaching their failure threshold. What he could not have foreseen was a silly SMART engineer at one of the hard disk manufacturers setting thresholds in the 90's! I mean, setting End-to-End_Error with a starting perfect scale value at 100, then the failure point at 99! There clearly is no margin for error there, so this is (like several others) somewhat experimental, and not something to worry about. The End-to-End_Error attribute is not a critical item, is flagged as Old_age, not Pre_fail. On the other hand, Spin_Retry_Count IS a critical item, so a failure threshold of 97 is unusual, considerably higher than I have seen any where else. Such a narrow margin of error may indicate some 'fragility' in this aspect of the drive. The implication is that as soon as it begins to show any Spin_Retry_Count issues at all, then the drive is very close to catastrophic failure. Just a reminder, Pre_fail attributes are the only ones that are considered critical, the only ones that affect the SMART pass/fail test. The other attributes (flagged as Old_age) are either informational or 'aging' items. They are similar to human aging attributes such as wrinkling, arthritic joints, lost teeth, grey hair or balding, etc. Critical attributes would be a heart beat, breathing rate, brain wave activity, successful Alzheimers test results, etc. You may have increasing aging attributes, be a little slower, have small memory issues, but so long as you can pass ALL of the critical attributes, you are still a productive entity. Hard disks are the same. A suggestion to Joe, perhaps the near_thresh test and indication should be skipped for certain attributes. I would suggest skipping any that are not Pre_fail, and any whose THRESH is 70 or higher, and perhaps any whose VALUE is 100 or higher. Edit: I should not have raised any concern about the 'fragility' of these drives. Time will tell what these high threshold values actually mean. It is possible that the drive engineers are now so confident in the robustness of these drives, that they don't expect these problems (Spin_Retry and End_to_end) to ever occur again!

Everything is completely fine. As you can see above, the VALUE number for both attributes is 100 (and did not change), which is essentially perfect. What caused the 'near_thresh' flag is that the SMART engineers have set some rather odd Threshold values of 97 and 99, which are very close to 100. Apparently what is being monitored here has to be either almost perfect or it is considered a Fail. Nothing for us to worry about here though.

Just to add a clarification, because it may be confusing to some that a drive seems to be working fine, yet the SMART report says it has FAILED. Part of the idea behind the development of the SMART system is to try to alert users to imminent failure BEFORE it is too late to save data. When a drive indicates a SMART failure, it is trying to warn you that there is a very high probability of complete drive failure in the very near future. The drive may or may not be fully operational at this moment, but even more catastrophic failure is very possible very soon. If there is any important data on the drive, you should attempt to relocate it as soon as possible.

A SMART report comes directly from the internals of the drive itself, so if a drive says it is failing, I would believe it! I agree that there are many inconsistencies with SMART reports, but in general - they ARE reliable if interpreted correctly. The problem is in knowing which numbers are important and which aren't, and unfortunately that changes with each drive manufacturer. Most of the very large numbers can be completely ignored, especially if they are 'raw'. Any attributes with 'Old_age' in the flag column can be considered Informational. Those marked as 'Pre-fail' are the critical ones. In your case, the Seek_Error_Rate has dropped too low. The line could be interpreted to read as: Seek_Error_Rate has dropped to the 28 percentile (from VALUE column), and previously had even dropped to the 26 percentile (from WORST column), which is lower than the 30 percentile rating (from THRESHold column) that the engineers at the drive manufacturer have deemed the minimum reliability percentile, below which this drive should be considered FAILED. Except for that one attribute, the drive looks great, including the Raw_Read_Error_Rate. Currently, it has a VALUE of 116, which is somewhat higher than 100! Again, as has been said many times before, ignore that raw value. The main raw values that ARE meaningful are Reallocated_Sector_Ct, Power_On_Hours, Power_Cycle_Count, Reported_Uncorrect, Airflow_Temperature_Cel, Load_Cycle_Count, Temperature_Celsius, Current_Pending_Sector, Offline_Uncorrectable, and UDMA_CRC_Error_Count (but possibly others too).

Syslog essentially confirms the previous comments, so hoping that the newer cable works better for you. An additional comment, you are running UnRAID v4.7 and your syslog shows some issues setting up the SAS support (not uncommon). V4.7 is still the official released version, but the included SAS card support was very young. For your hardware, I recommend moving to the later betas, because I believe the SAS support is better, more stable.

This errors keep on repeating. The syslog is 30MBs! The drive is 6.0Gbs but the board is 3.0Gbs, I doubt that could be the problem. Could it be the backplane in the Norco? There are at least 4 indicators of bad communications to the drive - degraded SATA link speed ("SATA link up 1.5 Gbps"), degraded UDMA speed ("configured for UDMA/33"), SATA error flag ("Handshk"), and drive error flag ("ICRC"). This is most likely caused by a bad SATA cable, but could also be bad power to the drive. Replace the cable ASAP, with a known good SATA cable, and test again. Just a note, what is usually most helpful from the syslog is either all of it in a zipped file, or at least the section that includes the very first occurrences of the error. The 6gbps vs 3gbps SATA speed difference should not be a problem.

The latest HWiNFO32 (v3.70) claims "Added new SSD SMART attributes". You would need to access it on a Windows machine though.

I would like to suggest to Joe that he add a little normalization to these line comparisons. If the value(s) in the VALUE or WORST columns are 200 or 253, then replace them with 100, and then compare them (but keep the original for display). This will eliminate some confusion, since these are not actually SMART value changes, just initializations. The only extremely remote case where this may not work as expected is with a few older Maxtor drives, that actually use a scale from 253 down to 1, but I don't think this would matter. All others are scaled from either 200 or 100. I would also suggest dropping the 240's and perhaps others, or at least find a way to 'deprecate' them, so if they exist and are different, are not given any significance.

That is really odd! Thanks for picking up on that, I have never seen that happen before. In particular, the WORST value is NEVER supposed to increase. The read error rate appears to have been reset completely, which I think may be a minor bug in the firmware for this drive model and firmware version. I suppose the manufacturers have a way to reset some values on refurbished drives, but that still seems like tampering with the speedometer before a resale.

That's actually a little unusual, but not a problem! The error rate is zero, and stayed zero. What intrigues me is that the other manufacturers and even Samsung before this used 253 to indicate that the attribute had not been used yet, but apparently Samsung has found a need for another internal use, and reserved 253 for it, making 252 the new UNUSED marker. The other thing that is a little odd is that they used a starting value of 100. The general trend in modern drives is to use a scale of 1 to 200, whereas before they used 1 to 100. You will often see in modern drives where some attributes, especially newer ones, use 200, whereas many of the oldest attributes still use 100. Perhaps for Samsung, this IS an older, long used attribute.