Joe L.

Try using the "-D" option. The SSD is apparently not responding to the '"ata" command set as expected by smartctl. preclear_disk.sh -D /dev/sda Joe L.

You used an older version of preclear_disk.sh. Current is version 1.6, and when lime-tech releases 5.0beta5 there will be a new version 1.7. The newer versions of preclear_disk.sh have some new added features and have improved their final report to make it slightly easier for noobies. (The actual clearing is the same) # Version 1.3 - Added logic to read desired "default" Partition Type from /boot/config. # - Added logic to save dated copies of the final preclear and SMART reports to a # "preclear_reports" subdirectory on the flash drive. # - Added "-R" option to suppress the copy of final reports to a "preclear_reports" # directory on the flash drive. (they are always in /tmp until you reboot) # Version 1.4 - Added "-D" option to suppress use of "-d ata" on smartctl commands # Added "-d device_type" to allow use of alternate device_types as arguments to smartctl. # Added "-z" option to zero the MBR and do nothing else. (remainder of the drive will not # be cleared) # Version 1.5 - Added Model/Serial number of disk to output report. # Fixed default argument to smartctl when "-d" and "-D" options not given. # Added intermediate report of sectors pending re-allocation. # Version 1.6 - Fixed logic to prevent use on disk assigned to array in 5.0beta4 version of unRAID Your disks look perfectly fine. Joe L.

I would suggest not using any option except the -w Invoke it as cache_dirs -w I think he issue is you limiting the depth cached to 3. The other Min and Max times adjust themselves automatically. Unless you have massive numbers of files in other top level shares, using the "-i" is also not needed. I personally use -e "data" because I have an old backup of older files under my "data" share that has over a hundred thousand files.

You understood correctly.

Version 1.6 of preclear_disk.sh has now been released. It is attached to the first post in the original preclear_disk.sh thread. The newest unRAID 5.0beta made changes to the format of the config/disk.cfg file that broke the "-l" option of preclear_disk.sh. The new version 1.6 of preclear_disk.sh may be used with both older and newer versions of unRAID. Have fun. Joe L.

I'm thinking you are right. The errors in the syslog are a result of the attempts to communicate with the disk failing.

Cool! I'm glad a few hours of me banging my head against the desk amounted to something useful for a change Thanks for all your hard work on this script, it is a great program! Version 1.5 of the preclear script is in place attached to the original post. - I fixed the bug you discovered, - I added the model/serial number of the disk to the output report stored in the preclear_reports subdirectory. (The device name might change over time, but the model/serial number will allow you to know which drive was reported on if looking at the files at some future time) - A added intermediate reports of sectors pending re-allocation. We should now be able to tell if they are being discovered in the post-read phase. Joe L.

The unRAID main page has DISK_DSBL_NP in the Array Disk Status section. The other four disks are listed as OK. NP = not present = currently un-assigned. It is expected. It will go back to OK once you re-assign and re-construct the disk. Oh yes, I did find the issue that caused the smartctl error you encountered. Your errors capture provided me the clue I needed. Thanks. I'll be putting out version 1.5 of the preclear script shortly. It was a typo on my part. It it errors out again, invoke it like this: preclear_disk.sh -d ata -A /dev/sdX It will work around the fact I did not initialize the device type correctly in version 1.4. Joe L.

Yes, that will certainly work. it will give me some time to figure out what is going on. Converting a precleared disk only takes seconds. What version of unRAID are you running? Joe L.

preclear_disk.sh -v will give you the version. If it does not recognize that option it is a very early version indeed. Basically your disk has stopped responding to any command. Type fdisk -l /dev/sdX or hdparm /dev/sdX and see if it responds at all. If it is like every other EARS drive, once it locks up it will take a power cycle to get it to respond again. So... stop your array, power down, power back up, and then try to see if the disk will respond to any command. Joe L.

A drive to be precleared cannot be assigned to the array. You are correct. Joe L.

Absolutely it is possible. Before re-allocating a sector it is first attempted to be re-written in its original location. If successful there is no need to re-allocate it. It does possibly indicate the original "write" was not successful. It is good the sectors did not need to be re-allocated. It could be an indication of a noisy power supply or a vibration issue that would make it tough for the disk to be written. The remaining two that are pending re-allocation are an issue though, since all detected in the pre-read should have been re-allocated in the write phase. Therefore I suspect the two remaining were detected in the post-read phase. As mentioned, I see another pre-clear cycle is in your future, and if the disk still has more pending sectors, a possible RMA. Joe L.

Best info ins in the wiki: http://en.wikipedia.org/wiki/S.M.A.R.T. Good luck finding conclusive information. (Other than the disk has not failed SMART of the VALUE is above the FAILURE_THRESHOLD) The status column in my final report will show the status from the SMART report if there was one, or "near_thresh" if the value is within 25 of its affiliated failure_threshold, and "ok" if the SMART report showed nothing else.. (I chose to put "near_thresh" as the status if a value was within 25 of its affiliated failure threshold. The idea was to bring it to your attention. I did not think I'd ever seen a failure threshold of 99 with a starting value of 100 as your manufacturer has done. You have two values where the manufacturer decided to put the failure threshold only a few counts higher than their failure_threshold. Their raw values have no counts, so odds are high the disk is perfectly healthy even though the failure threshold is near. Other that that, enjoy your new disk. (Oh yes, there is already a newer version 1.4 of the preclear script, but it just adds a few new features for special purposes and fixed the "Step 10 of 10" cosmetic bug where I displayed the "DONE" line one too high on the screen overwriting the "Step 9 of 10" line. Your version would have worked perfectly) Joe L.

Unless you started the preclear using "screen" it is easy to know the status. The preclear was terminated when the telnet session terminated. If you are using the 1.3 or 1.4 version of preclear you will find a preclear_reports directory on your flash drive if it completed. In that directory will be the final reports. Otherwise, you can get an idea of how far it might have gotten by looking in the /tmp directory. If there is a file named /tmp/zerosdX, where sdX = the three letter drive designation, you can type tail /tmp/zerosdX to get an idea how far it got. To see when it quit you might be able to look at its time-stamp on the file with ls -l /tmp/zero* That file is only used when actually zeroing the disk. If the preclear terminated before it got to the "write" phase, it will not be present. You will need to start it as if it had never performed the process at all. If the last line in /tmp/zero* does not have the full number of bytes on your disk, it would have terminated in the write phase. You can re-start the process using the -W option if the "/tmp/zero*" file is present. It will then do only the "write" phase and post-read-verify phases. preclear_disk.sh -W /dev/sdX If the "write" phase was completed, or you suspect it was, you can test if the pre-clear signature is present by using preclear_disk.sh -t /dev/sdX If it is you can use the new "-V" option to perform only the post-read-verify phase. preclear_disk.sh -V /dev/sdX You can use the -A option on any of the above preclear_disk.sh commands to specify a 4k-aligned sector 64 start. You should download and use the latest version of the preclear script. I've been constantly improving the output report. The last version as of this post is version 1.4 You can see the version by typing preclear_disk.sh -v Joe L.

None of my four pre-clears have taken over 27 hours. Now I'm concerned. It just indicates you have fast disks and a fast disk controller.

You must have a very fast (and very nice) disk controller in that server of yours. I was wrong, as the preclear did run in 26 hours. The report says it all. The only attribute that changes in any way you might care about was the drive temperature. It went from 28C to 31C. (You must have good fans too.) Joe L. PS. You are also running the slightly older version of preclear. I posted version 1.4 this morning. It has a few new features, but none that changed the output report. Joe L.

preclear_rpt_sdc_2011-02-04 ? Post the contents of that file.

First, that is a smartctl report, not a preclear_disk.sh report. Second, we really cannot tell much from that report other than it cannot be from the end of a preclear cycle since it only shows 26 hours of operation. From what I been hearing from other unRAID users, it takes between 33 and 35 hours to run a full cycle on a 2TB drive. 26 hours seems a bit too little time. I suspect that might be a report from the start of a preclear cycle.

Your version of the preclear script may be 7 versions old. (I've been busy ) What do you get when you type: preclear_disk.sh -v # Version .9.9 - Changes to not perform pre-read in multi-cycles of use immediately after post-read # - added "-l" option to list device names of disks not in the array. # - modifications to final output report for easier interpetation # - modification to name the temp files after the disks being cleared. # - Added ability to start partition at sector 64 with -A option. # Version .9.9a - improvements to analysis report # Version .9.9b - more improvements to analysis report # - fixed bug when parsing config/disk.cfg for existing assigned disks. # Version .9.9c - fixed bug where date format change in 5.0 unRAID changed and # caused "-l" option to not work as expected. # - more improvements to analysis report # Version .9.9d - more improvements to analysis report # Version 1.1 - added -C 64 and -C 63 options to convert precleared drives from # sector 63 start to sector 64 start. # - added display of command line arguments to initial confirmation screen # - added -W option to skip pre-read phase and start with "write" phase. # - added -V option to skip pre-read and "clear" and only # perform the post-read verify. # Version 1.2 - fixed "-l" option to not exclude disks with only a "scsi-" entry in /dev/disk/by-id # Version 1.3 - Added logic to read desired "default" Partition Type from /boot/config. # - Added logic to save dated copies of the final preclear and SMART reports to a # "preclear_reports" subdirectory on the flash drive. # - Added "-R" option to suppress the copy of final reports to a "preclear_reports" # directory on the flash drive. (they are always in /tmp until you reboot) Step 1. Download the newest preclear_disk.sh Step 2. If you have about 10 hours can use the new verify feature on the disk you just pre-cleared. It skips the pre-read and zeroing, and just does the post-read verify and final report. Type preclear_disk.sh -V /dev/sdd Then, when it is done look in the preclear_reports directory on the flash drive. Joe L.

Those are the raw smart reports. The final preclear report should be available in the preclear_reports subdirectory of the flash drive. (assuming you are using the new preclear script.) It tells you in English if the preclear was successful. The SMART reports do not. Joe L.

It entirely depends on the manufacturer as to what it indicates. Near-threshold simply means the VALUE is within 25 of its failure threshold. Since the manufacturer gets to "normalize" the data, it could have millions of "errors" before deciding to change the normalized value down a count or two to where it hits the failure threshold. So... you are more informed, but nobody has a clue why the manufacturers set the thresholds as they do. Since the "Spin-Retry" count is zero, I'd guess the disk has never had to re-spin a disk to get it up to speed. Same with "End-to-End" errors.. The Raw value is zero, so (assuming they show the raw data) it too has never failed. I would not worry too much about them. I wish interpreting SMART reports was easier, or there was a true "standard" all disks followed, but there is not. Joe L.

You will find a copy of it in your syslog. (if you've not rebooted) Joe L.

There is no need to post the smart reports. But, you did not post the final preclear report, and that would have told you the same as I will I did not see any attributes marked as FAILING_NOW There are no sectors re-allocated, or pending re-allocation. Enjoy your new drives. Joe L.

No, they crash on their own.... Three blue-screens of death this week on my Vista Laptop. Following "microsoft's" advice to debug it says the problem is fixed in SP1. But I have SP1 installed, and everything else they have as updates... all except IE8 and Silverlight. (I want neither) Oh yes, memtest run overnight come up clean... so it is not ram related. So no, I don't have to reboot every once in a while.... it never stays up that long... argh....

No. This is not "windows" No need to reboot. You almost never need to "reboot" unless you are installing a new version of unRAID, or you will be adding/removing disks or other hardware, or some wayward process has used up all your system memory (and processes were killed trying to make room for running ones) Joe L.