Everything posted by Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
Everything looks normal. Enjoy your new drives.
-
Preclear.sh results - Questions about your results? Post them here.
Yes, it is actually quite easy in this case. Your pre-clear terminated as soon as you terminated the telnet session when you turned off your desktop. Only the smart report from before the pre-cleat is in your log. Joe L.
-
Pimp Your Rig
Nice looking server. You can also probably fashion a small 2 disk "rack" mounted just over the power supply if you get crunched for space in the front of the case. It might need its own fan, but there's plenty of room for it. The white plastic disk mounts must make it very easy to install drives.
-
Preclear.sh results - Questions about your results? Post them here.
There were no errors. In fact most of the "normalized" values IMPROVED. Prior to the pre-clear, the normalized value for Raw Read Error Rate was 114, After it was 118. Higher numbers are better. If the error rate goes BELOW the error threshold (006) the drive will be considered as failing. Prior to the pre-clear, the "normalized" Seek-Error-Rate was 064, after it was 064, It was unchanged. Prior to the pre-clear the highest temperature recorded by the drive was 37, after it was 39. The "normalized" value of 65 is not below the "failure threshold" of 45 for that parameter. Prior to the pre-clear, the "normalized" Hardware ECC Recovered value was 36, after it was 52. It also improved. Its failure threshold is 0. All drives internally handle error correction. All drives have internal errors and re-read and perform error correction. some drive models report "raw" numbers in the "raw" column, but they are meaningful to the manufacturer only. (with few exceptions. The re-allocated sectors, pending re-allocated sectors, and temperature being the exceptions) Enjoy your new drive. It looks great. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
I think something is flaky. Each time there are sectors pending re-allocation in the result, but no re-allocated sectors. The only way I know that can happen is if the sectors are able to be written to their original locations on the disk (the disk tries that first) So, to me, it indicates the ability to read what was written on that disk is not reliable. (constantly different sectors pending re-allocation) The raw-read-error rate is a number that has no meaning to anyone but the manufacturer. The normalized value is continually dropping (towards the failure threshold of 51, but nowhere near close to it YET) That is not a good sign, but seems to go hand in hand with the pending re-allocation errors you are seeing. My vote... RMA the drive. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
Pre-read we just ignore what we've read and send it to /dev/null Post-read we sum all the bytes read and verify all zeros are being read back where expected. Yes Depends on what else is going on at the same time. Since the clearing process sets the geometry, and read-block-size is based on the existing geometry, I suppose it could vary some.
-
Preclear.sh results - Questions about your results? Post them here.
UNC errors are UNCorrectable read errors. (unreadable sectors) Basically, you'll see them in the SMART report as sectors to be re-allocated unless the process of writing zeros to the drive in the next phase is able to re-write them in their original locations and have them readable. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
No, it does not have any idle periods. It is a mystery. It is either reading, or writing the disk... and doing a lot of it at that.
-
Preclear.sh results - Questions about your results? Post them here.
Do not swap cables and add drives at the same time. Do it as two steps. Stop array Power down Swap Cables Power Up Re-assign drives on devices page as needed Start Array Then Stop Array Assign new drives Start Array Make certain ONLY the new drives show as un-formatted. If any others show as un-formatted DO NOT PROCEED. Press "Format" button on management console button to Format the new drives. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
All the disks look fine. You can also install "screen" It allows you to connect and disconnect from terminal sessions without terminating the processes running on them.
-
Preclear.sh results - Questions about your results? Post them here.
No, they are perfectly normal. In neither parameter is the "Current Normalized value" anywhere near the failure threshold.
-
Preclear.sh results - Questions about your results? Post them here.
My background is in reliability so I do know a thing or two about the bathtub curve. Many manufacturers will do ESS (Environmental Stress Screening) or HASS (Highly Accelerated Screening) on their products before shipping them. However since hard drives are a commodity I doubt that any of them do it. Maybe on their enterprise products which carry a higher price. The intent is to stress the products so that latent mtg. defects will be found prior to operational use. Essentially they truncate the front part off the bathtub curve so that all the customer is exposed to is a constant, very low (hopefully) failure rate for many years prior to climbing up the other side of the bathtub curve which would be associated with failures due to wearout. Your preclear process is essentially a form of HASS. We're stressing the drive to determine if there are any defects - the thought being that if it lasts X number of hours without failure (i.e. SMART errors) then it should last a long time. The only problem is that most companies tailor the length of their ESS or HASS tests based upon their knowledge of the bathtub curve specific to their device. Since we lack that knowledge all we can do is guess. I'd say that something like 50-100 hours would be reasonable, so the number of recommended cycles would vary depending upon the size and speed of your drive. You are right and like I said above, stressing the drive will get you into the constant, very low failure rate portion of the bathtub curve. There is no such thing as a failure rate of zero. But you can always just skip the several cycles of preclear and install your drives fresh out of the box. Let me know how that works out for you. Wow, thanks for the interesting description and insight. I know the basics, but obviously you are much more familiar with the concept of stress testing. Remember ... There are only two types of hard disks. No, not IDE and SATA The two types are.... 1. Those disks that have already crashed/failed. 2. Those disks that have not yet crashed/failed.... but will... just wait a bit longer.
-
Preclear.sh results - Questions about your results? Post them here.
I will check the cables. I'm running a new US budget box build. Is there any reason the 400W power supply is not enough? We have no idea... How many disks do you have attached, how many are "green"? What specific 400 Watt supply? Is it a single 12 Volt rail supply? Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
Power-Off_Retract_Count is usually the count of how many times the disk heads were retracted in a power loss. Load_Cycle_Count is how many times the disk heads are loaded from their parked position. Both counts incremented by 1. (as if the disk lost power, it retracted the disk heads, then power was restored, and it re-loaded them) I'd look for a loose power connection to the drive. Or, it could be your power supply is not up to the task, or you have a bad splitter, back-plane, card-rack, etc... It is not normal to see those counts increment in a pre-clear cycle.
-
Preclear.sh results - Questions about your results? Post them here.
Good question... To know how long to run a drive before "early" problems are discovered would be a whole research topic in itself. I'd guess the term "bathtub curve" is the way it is described. If you can get a full pre-clear cycle on a modern disk and it shows no problems, then you've run it fairly hard for 20 to 30 hours or so. It is a longer burn-in period than most manufacturers will provide. If you have the time and do not need the disk in the array immediately, go ahead and do another cycle. If no problems showed, and you need the disk in the array now, assign it and start using it. I usually run several cycles on my disks if I'm not pressed for time. I would guess many do not do multiple cycles, but it was a requested feature so I even added a command line option for it preclear_disk.sh -c N /dev/sdX where N is a number from 1 through 20. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
Well that depends. Any sectors pending reallocation is not good. But it's ok as long as there not thausands of them and they do not increase over time. So what you should do it to run a few more times the preclear script and check if there will be an increase in "5 Reallocated_Sector_Ct " and the pending sectors. After you run the next preclear, the 17 pending sectors should have been reallocated and appear in "5 Reallocated_Sector_Ct ". If there is no increase in pending sectors, you'll probably be fine. Just keep an eye on it from time to time by running some SMART tests while it's in use in your array. The statement is true... but remember this... those pending re-allocation must have been detected during the post-read phase. If they were detected in the pre-read phase, they should have already been re-allocated when the zeros were written to the drive. Therefore, the advice given is sound. Run the pre-clear script several more times on that drive. I realize it will take a while, but it is a LOT easier to get the drive replaced now it is continues to have errors than after it is in your array and it holds your data. As far as "raw read error rate" the raw values for that attribute are usable only by the manufacturer. We can only look at the "normalized" values. Raw_Read_Error_Rate 0x002f 197 195 051 Pre-fail Always - 291 The "worst" value was 195, the failure threshold is 51. You are nowhere close to "failing" All drives have raw-read-errors, they all re-try. Some report it on the smart report, others do not. The raw-read-error does not mean the "read" failed, just that it had to re-try. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
Many disks do their own tests when not being accessed. The "short" and "long" tests often mentioned are two types of those tests. Some drives also re-callibrate themselves every so often. These are all considered off-line tests. The message simply indicates the off-line test was terminated when the drive was accessed. You can ignore it. You would get the same type of message if a long test was requested and you asked the disk to spin-down. Joe L.
-
Preclear.sh results - Questions about your results? Post them here.
If any of the parameters "current normalized value" drops below its affiliated "failure threshold", it will show as FAILING_NOW None of the normalized parameters is anywhere near its failure threshold.
-
Preclear.sh results - Questions about your results? Post them here.
Looks good to me too. no re-allocated sectors, no sectors pending re-allocation, no other parameters "failing"
-
cache_dirs - an attempt to keep directory entries in RAM to prevent disk spin-up
yes.
-
Preclear.sh results - Questions about your results? Post them here.
These lines make me thing you have the SATA ports set to emulate an IDE drive since it is slowing down to PIO speeds in an attempt to communicate with the drive. Aug 9 07:56:17 Tower kernel: ata3: hard resetting link Aug 9 07:56:19 Tower kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Aug 9 07:56:19 Tower kernel: ata3.00: configured for UDMA/133 Aug 9 07:56:19 Tower kernel: ata3: EH complete Aug 9 07:56:19 Tower kernel: sda: detected capacity change from 0 to 2000398934016 Aug 9 07:56:21 Tower kernel: ata3.00: limiting speed to UDMA/100:PIO4
-
Preclear.sh results - Questions about your results? Post them here.
I apologize. The communications with the drive are very poor, indicating possible a bad SATA cable or poor connection. Lots of the errors indicate the drive is attempting again and again to communicate with the drive and it keeps trying to reset it. It could of course be a bad drive, or a bad drive controller, but the cabling is the most likely suspect.
-
Preclear.sh results - Questions about your results? Post them here.
Google is your friend...
-
Preclear.sh results - Questions about your results? Post them here.
ALL disks have raw read errors. Some report them, others do not. The numbers in the "raw" column are meaningless to anyone but the manufacturer. The only values we can interpret are the "normalized" value (100) and the failure threshold (051). In this case, the normalized value has not budged from its initial factory value of 100, and it is nowhere near the pre-failure value of 51. In other words the drive is perfectly fine. The ONLY raw values we can use are the sectors pending re-allocation and the sectors already re-allocated. The temperature is usually readable, but even then on occasion a drive will report temperatures below ambient. It is probably the raw temp on those model drives needs to be offset to get to the actual value.
-
Preclear.sh results - Questions about your results? Post them here.
The circumference of those inner cylinders is a lot smaller than the outer. The disk manufacturers like to boast about the peak speeds on the outer cylinders, they seldom talk about the slower sustained speeds on the inner cylinders. :'(