justaguy

The rows with "<" are the readings before the test, the ">" are the readings after the test. So, your raw read error rate *improved* over the course of the test. For SMART parameters, you are supposed to look at the "normalized" numbers of "101 099 006" in the middle. The value 101 is the current reading of your drive (lower is bad), and the value 099 is the lowest (worst case) it's had in the distant past. The value 006 is not a reading from the status of *your* drive, rather it is considered to be the threshold when you should consider your drive to be junk. When the 101 or 099 values drop below 006, throw out the drive. For Seagate drives, the "raw" value (number after the dash -) is not a direct count for some of the SMART parameters. For raw read error rate, you cannot interpret that value directly, because it is some encoding of various data. The seek error rate is unchanged. Again, the raw value cannot be interpreted. The value 078 is a good measure above the threshold of 030. High fly writes are a sign the disk head comes too high off the media to do a reliable write. The normalized value got slightly worse over the course of the test, dropping from 039 to 031, but you don't need to worry until it reaches 000. The count of these incidents increased from 61 to 69. Due to the slight increase, you might be a bit but not overly concerned. You should continue to monitor this value. Temperatures look good and cool. ECC recovery rate has actually improved from 029 to 055. The worst value in drive's history is 025, and you didn't even come close to that. Worry only when this value reaches 000, or if it starts to reach new minimums. Just to note, this thread should be regarding discussion of the script itself, not about interpreting its results. The thread for interpreting results is here: http://lime-technology.com/forum/index.php?topic=4068.0

I have unRAID running on both an Acer h341 and h342 for about 1 month without any problems. I have reconfigured the system in various ways, written tons of data, done parity checks, etc. I have not found a problem yet. However, I have not yet migrated critical data to the boxes. I have unRAID installed on the internal 256MB of flash on an internal USB port. To boot unRAID, I made my own VGA cable from a few spare parts: -- VGA connector with ribbon cable from an old video card -- 2.5inch IDE hard drive female header from an old notebook, cut down to 26-pins using a Dremel You need the VGA cable to change the boot sequence from the hard drive to the USB flash. The main drawback is the BIOS self-resets to boot from the hard drive if you ever remove & reinsert any hard drives. Funny, the h342 reports cooler temperatures than the h341. I reversed the cooling fan, and it runs cooler. I then replaced the fan with a Noctua 140mm fan (fits in 120mm footprint) and it runs even cooler, but I'm not sure it's worth it. A few mods I'd like to do: -- get a low-profile PCIe x4 SSD some day to act as a cache drive -- track down the chipset pins and traces for the 6th SATA port on the motherboard, maybe I can solder a new SATA port -- solder a 4-pin connector for a CPU cooling fan (I think h340 has a connector already; h341/342 has board space but no connector soldered down) Guy

Joe, Thanks a lot for your preclear script. You have a lot of clever things in there, eg modifying the partition table using echo and dd ! It took the script 105 hours to complete 3 passes on four 2TB Seagate ST32000542AS (I cleared all 4 disks in parallel on an Acer h342, an Atom dual-core machine). I modified your preclear script so the SMART differences will be printed a bit more clearly. In particular, the table of attributes is separated from the main report and the rows are better interleaved 1-by-1 to better highlight differences. I've attached my new script... but please note I also shortened the short_test lengths because I'm impatient. Do you mind if I suggest a few other improvements? 1) On passes after the first pass, there is no need to do a pre-read, because the post-read of the previous pass already read all the sectors. This would allow for more write-test passes in the same period of time. 2) On each pass, write a different value to the sectors rather than all 0's. Starting with data=0, maybe write the value "data = data ^ 255 ^ (pass-1) ^ (pass)" for each pass. Starting with pass=1, this should write the sequence 254, 2, 252, 4, ... (255-pass), (pass), ... On the final pass, you can write 0's. This will make it harder to use 'sum' to verify, but it will better test the underlying medium and detect when data is not being written correctly on successive passes. Thanks, Guy preclear_disk_guy.zip