Joe L.

When I see a disk with a lot of sectors pending re-allocation after a pre-clear it indicates the sectors were un-readable in the post-clear read. (If identified in the pre-read, they should have been re-allocated when written with zeros) The other possibility is a poorly regulated power supply, causing read errors. Or, drive electronics sensitive to noise on the power supply lines. Right now, I see a drive with a fair number of re-allocated sectors (44 ) and a lot more pending re-allocation ( 149 ) I'd run another pre-clear cycle, and if the numbers continue to increment, RMA the drive.

No. But is this a small drive? (3 hours is a very short time, I'm suspicious unless the disk is a small one)

Look here: http://en.wikipedia.org/wiki/S.M.A.R.T.

Use the "-p NNN" option to cache_dirs to set the cache pressure higher than the value set by cache_dirs by default. I would suggest a value of NNN somewhere between 100 and 200, perhaps higher. It sounds as if the copy process is running out of memory and cannot get any since the disk buffer cache has been instructed to horde it. Try cache_dirs -q to quit the currently running cache_dirs followed by cache_dirs -p 200 to re-start it with a new cache_pressure value. Joe L. Joe L.

I already did, but you are welcome to edit and improve it even more.

Easy. If you run out of memory and processes start getting killed off it is too low. (Hint: emhttp and smbd tend to be some of the first to be killed off) As stated... pitch in and help, even if just pointing out what is out of date.

The wiki needs updating actually. My personal experience is unless you have more than 512Meg you can run out of ram for processes as it is all horded for disk buffer cache. (and I hav no idea how much is enough) Cache_dirs already sets cache_pressure. By default it sets it to 10. Even that is too low a value for me on my server if I'm trying to perform certain tasks. If you are running add-ons, either set it higher (200), or at least put it up to 100. To do that you use the -p NNN option.

Your guess is as good as mine. It seems to indicate the first smart test failed. Perhaps SMART reporting was not enabled on the drive, or it was not initialized as expected.... Or it could be one that SMART is unable to address in some conditions. I'd try a quick test with preclear_disk.sh -t /dev/sdh command to be sure the pre-clear actually completed.

Looks real good.

Since the sectors seem to be re-written to their existing locations (I see no change in the re-allocated sector count, only "pending sector") I would not be so quick to point the finger at the disk drive. It could be the drive, but it could just as easily be the power supply. Basically, the drive seems to be able to re-write the sectors in their existing locations. The question is what made the "writing" of the sector un-reliable the first time? Was it the disk itself? vibration? noise on the power supply? Almost impossible to tell from an outsiders point of view. Since there are continual sectors pending re-allocation I'd just start an RMA stating that fact. You'll probably never get the drive to fail a smart test, at least not in the next weeks/months. Joe L.

As you said, writes to the disk were failing... and eventually the syslog might have used up all RAM and crashed the server. Good you killed it. Joe L.

You would not have been happy having that drive in your server. Yes, most drives preclear just fine... and then there are those, like yours, that show their true colors. Just think, 99.99 % of the people installing drives have no idea at all if they are readable, and most will only know when their program/and or data is subsequently unreadable. Most will blame it on Microsoft... Joe L.

You are getting tons of "media errors" (Un-readable sectors) If you get a smart report on the drive you'll see them as sectors pending re-allocation... ( or you can wait, the final preclear report will show them too) Joe L.

ok your choice, but they will not consider it failed... most disks have several thousand spare sectors, and you've apparently used NONE of them. Look closer... you had 10 pending re-allocation at the start, and most, if not all were NOT re-allocated, but instead were re-written in place in their original sectors. (You did not show any output in the Reallocated Sector counter, so it must not have changed) To me that indicates a different class of problem, one where the writing to the sector was poorly done and when re-written it worked. That could easily be a vibration issue, or a power supply issue, with noise on the power supply leading to a poor quality written sector. Of course it could be poor electronics in the drive itself too, but it points less towards defective magnetic surface on the platters.

Probably... I would never expect to see a "Current Pending Sector" in the post-clear smart report. That's because they should all have been identified in the pre-read phase, and re-allocated in the writing of zeros. The post-zeroing phase should therefore not have detected any additional un-readable sectors, yet it appears it has. I'd run it through another cycle or two, and see if that last sector pending re-allocation gets re-allocated and no others show themselves. Sorry to say, but a continual trickle of un-readable sectors is not an indication of a healthy drive. If you only have a few, and the number do not increment when you continue to use the drive, then you should be OK. Otherwise, you are asking for constant random read errors. All un-readable sectors should re-allocate themselves when you preclear a drive, as it writes to every sector on the disk.

All drives have raw read errors... Some report them some do not. The actual number reported is meaningful only to the manufacturer. Notice that the "Normalized" value of 200 is unchanged and nowhere near the failure threshold of 51. Your drive looks fine. The other changes were the values changing from the factory initialized 253 value to the starting "normalized" value of 200. Joe L.

Either that or the SATA or POWER cable to it came loose. If it is the drive, it is good that it failed before you started using it for your data. FAR easier to RMA before you put it in the array. Joe L.

Correct. If the heads did not load it would be a bad thing indeed. Joe L.

Correct except that your "current" values for all those you included are 200. (The line with a leading "<" is from the smart report prior to the pe-clear, the lines with the leading ">" are from the smart report after the pre-clear. The 100 (or 200) values are initial values set by the manufacturer. In many cases, they start at the factory with a value of 253 and change to either 100 or 200 as soon as the drive is put into service by an end-user. The value then adjusts itself over the lifetime of the drive based on its internal performance. You are correct in that any parameter where the "current" value goes below the threshold will be considered as failed. Joe L.

All drives have raw read errors, some report them, some do not. The number you see has meaning only to the manufacturer. For that attribute you can only look at the "nomalized" value of 100. It is un-changed from its initial value of 100, and nowhere near the failure threshold of 16. If is good that your disk head loaded once. I am a tiny bit confused by the "Power-Off-Retract-Count" since I really did not expect the disk to be powered off. You might double-check your power connections. Joe L.

Those last two line indicate there is an issue. Although the number if pending sectors is not high, there should not be any after writing the drive with zeros... That indicates that 15 were detected in the post-read phase. since we do not see any that were re-allocated, it appears as if they were re-written in place on their original sectors. I'd try one more pre-clear cycle, and if it does not progress at a normal speed, or has any re-allocated sectors or sectors pending re-allocation, RMA the drive.

That might explain why they stayed cool.

Hoe is good because im already moving data It is fine. The only counter that incremented was the "load-cycle" counter. And if it had NOT incremented there would have been a HUGE issue, because it would then indicate the disk heads did not move from their parked position. Enjoy your new drive. for now, at least, it is working well. (good cooling... the temp did not change from 29C at its start. You must have good fans) 04:16 Tower preclear_disk-diff[32619]: ============================================================================ Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Disk /dev/sdc has been successfully precleared Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Ran 1 preclear-disk cycle Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Using :Read block size = 8225280 Bytes Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Pre Read Time : 7:34:51 (73 MB/s) Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Zeroing time : 7:18:06 (76 MB/s) Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Post Read Time : 14:48:50 (37 MB/s) Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Last Cycle's Total Time : 29:42:54 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Total Elapsed Time 29:42:54 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Disk Start Temperature: 29C Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Current Disk Temperature: 29C, Oct 21 04:04:16 Tower preclear_disk-diff[32619]: == Oct 21 04:04:16 Tower preclear_disk-diff[32619]: ============================================================================ Oct 21 04:04:16 Tower preclear_disk-diff[32619]: S.M.A.R.T. error count differences detected after pre-clear Oct 21 04:04:16 Tower preclear_disk-diff[32619]: note, some 'raw' values may change, but not be an indication of a problem Oct 21 04:04:16 Tower preclear_disk-diff[32619]: 63c63 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: < 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 76 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: --- Oct 21 04:04:16 Tower preclear_disk-diff[32619]: > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 77 Oct 21 04:04:16 Tower preclear_disk-diff[32619]: ============================================================================ Oct 21 04:04:16 Tower preclear_disk-diff[32619]:

I started on it quite a long time ago... Just never got too far. Perhaps you can finish it for me... I wrote the comments already... just need to fill in the code: analyze_for_errors() { err="" if [ "$2" = "" ] then sm_err=`analyze_smart $1` else pre_err=`analyze_smart $2` post_err=`analyze_smart $1` sm_err="$pre_err $post_err" fi echo -e "$sm_err" } analyze_smart() { # First, check overall health err="" overall_state=`grep 'SMART overall-health self-assessment test result:' $1 | cut -d":" -f2` if [ "$overall_state" != "PASSED" ] then err="$err SMART overall-health status = $overall_state\n" fi # next, check for individual attributes that have failed. failed_attributes=`grep 'FAILING_NOW' $1` if [ "$failed_attributes" != "" ] then err="$err\n *** Failing Attributes *** \n$failed_attributes\n" fi # next, look for sectors pending re-allocation # look for re-allocated sectors # look for any attribute within 25% of its threshold for failure. echo -e "$err\n" }

All drives have raw read errors. some report them, some do not. The "normalized" value is 100, unchanged from its initialized value from the factory. The failure threshold is 51. You are in fine shape.