BRiT

Yes. I now run at least 3 preclear cycles on all new drives. I've had a drive or two pass the first pass but die on the second or third. Hard drives failures tend to fall into the bath-tub curve. It's best to get past the initial part before you trust it with your data. The last drives I added to the array went through 5 cycles. Yes, that's around 150 hours of preclear on each one. Fortunately you can run preclear on different drives at the same time.

You're reading that SMART attribute wrong. The raw value of RAW_READ_ERROR_RATE is 0. Your nominal value is "100". The failure threshold is "51". Last I checked, 100 > 51, so the drive is not failing. ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 100 252 51 ok 0

Yes. Pre-clear was specifically made so there would be no array downtime. You can preclear drives while your main array is online.

You can still use them, you merely need to control drive spin down some other way.

How do you have the SATA controller setup in bios? Did you enable AHCI?

At this point on unRAID 5.0 I'd go the other way ... try running smartctl without any "-d" options at all and detect errors to try it with "-d ata".

No. If you close the telnet window your preclear session will be stopped. To do so, you need to use screen to run the preclear session so you can detach and leave the process still running.

You merely read the following summary:

1. Use the -c option (lowercase c) followed by the cycle count.

Yes, it's been asked before and it can be done.

I know the OCZ SandForce-based drives have their own meaning to the SMART attributes. My OCZ Indilinx Vertex 1 drive barely implements SMART and the values it returns have no meaning to consumers. EDIT: Here's the SandForce SMART information: http://www.ocztechnologyforum.com/forum/showthread.php?75786-SMART-Attributes-for-Sandforce-SSD-s-%28Agility2-Vertex2-VertexLE%29

You can let the preclear finish and then use the -C 64 option to adjust it from a Sector63 aligned to a Sector64/4K aligned.

Just waiting a few seconds typically 30 seconds is more than enough will have cache_dirs rescan. It is continually rescanning your directories by using the "find" command. There is no need to stop and start cache_dirs to force rescans.

Another possible means of determining if you have HPA is manually issuing the following command. This will probe all of your drives, including your USB Flash drive, so it's natural to see an HDIO_DRIVE_CMD failed for that drive. This takes the guesswork out of knowing what your drives are. hdparm -N /dev/[hs]d[a-z] /dev/sda: max sectors = 312581808/312581808, HPA is disabled /dev/sdb: max sectors = 3907029168/3907029168, HPA is disabled /dev/sdc: max sectors = 3907029168/3907029168, HPA is disabled /dev/sdd: max sectors = 3907029168/3907029168, HPA is disabled /dev/sde: max sectors = 3907029168/3907029168, HPA is disabled /dev/sdf: HDIO_DRIVE_CMD(identify) failed: Invalid argument /dev/sdg: max sectors = 3907029168/3907029168, HPA is disabled /dev/sdh: max sectors = 3907029168/3907029168, HPA is disabled

Usually the fix is they are actually reallocated. It's a little odd that they were removed from the pending reallocation list but were not actually reallocated. Perhaps they were able to be properly read during the preclear and thus removed from the pending list. I would run another preclear cycle on the drive to see how it behaves. Maybe Joe L or someone else would know better.

The new report format of the preclear_disk.sh is all you need to look at to determine if things are good or not.

Feel free to modify your own "go" script to use the /bin/beep command. For instance: beep -f 700 ; beep -f 500 ; beep -f 700 ; beep -f 500

The first version to support advanced format drives also includes the new report format as well. It was released on Jan 14, 2011 as Version .9.9. I know it at least displays the results to standard out. All you have to do is look at the display used to invoke the script. In my syslog I also have the human readable results, it's listed as "preclear_disk-diff". How did you invoke the script?

It has no effect on the array, so feel free to keep it online.

I'm sorry to hear about your Vista grief. I wish everyone could have the kind of success I have with my Windows and Linux systems. I've had success with my Windows 7 development environments. The only need to reboot is for the rare installing of new devices that require additional device drivers or system services which is the same case for Linux. Sometimes I don't need to reboot in Windows 7 with some of the device driver upgrades, like for the NICs and Graphic Cards. Anyways, back on topic... Any thoughts to having preclear_disk.sh do a quick version check on startup against the unMENU repository to see if there's a newer version available, if so prompt the user if they would like to continue anyways? I'm not proposing a self-updating feature, just a quick warning to the users to upgrade. It's been nearly two weeks since your report simplifications and there's still people asking for feedback on the old formats. Now I know this won't help those running the older versions, but it would cut down on this sort of thing in the future.

To be fair, the latest versions of Windows hardly need reboot either.

Answered your question in the other thread.

For future reference, always upgrade to the latest version of preclear_disk.sh available at the time BEFORE you start your preclear cycle(s). The new results format enable you to self diagnose with ease. We can not tell if your disk is good since you did not include the full SMART report. We can only tell you that 3 attributes changed normalized values that are no where near their thresholds. If the disk was failing before the preclear on some attributes they're failing the same way after the preclear. If the disk was not failing before the preclear on some attributes, they're not failing the same way after the preclear.

For future reference, always upgrade to the latest version of preclear_disk.sh available at the time BEFORE you start your preclear cycle(s). The new results format enable you to self diagnose with ease. Your friend's drive is fine.

That is absolutely not normal. What size do they report as inside of BIOS? You might need a motherboard BIOS update, or at worst case you might need a new motherboard or a dedicated SATA controller card.