Joe L.

I'd run another pre-clear cycle on it. If additional sectors are re-allocated, it might be a candidate for an RMA. If nothing changes, then go ahead and use it, most disks have several thousand spare sectors. Just keep an eye on it. If you see the number of re-alllocated sectors increasing, or continual "read" errors on the web-management console, consider the RMA. Oh yes, I see you are using an older version of the pre-clear script. Please download and use the newest one for your next cycle. I've been making continual improvements in the output report. Joe L.

The above is normal. Those are all child processes of the cache_dirs script. Correct. They are child processes, one per disk in your array, to keep you from seeing false "unformatted" messages when you attempt to stop the array and cache_dirs is running. As stated, they are normal. Joe L.

Good question. I'd use the stock one when checking the parity drive and the NOCORRECT one when checking the data drive. (Otherwise, it might use an un-readable data drive to potentially update parity) You could use the NOCORRECT for both, but it does no harm if it fixes parity when checking the quality of the initial load of the parity drive.

Looks good. I added two steps to your proposed upgrade procedure. next steps to replace parity, rebuild, perform parity check to ensure written parity is readable then replace a data drive, and rebuild one more time then perform parity check to make sure data drive written is readable/

If you pre-cleared it already, and it was not yet assigned to the array, and you pre-cleared it without a jumper, you can use: preclear_disk.sh -C 64 /dev/sdX (where sdX = your disks's device) It will convert the pre-clear signature to use a starting sector of 64. It only takes a few seconds. It will only convert if it is currently "precleared" and you did not change the jumper setting since you cleared it. If not, use the "-A" option and run it through another cycle. Joe L.

this says it all: ** Changed attributes in files: /tmp/smart_start_sdb /tmp/smart_finish_sdb ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 131 200 51 ok 5388 Reallocated_Sector_Ct = 50 200 140 [color=red]FAILING_NOW[/color] [b][color=red]1195[/color][/b] Reallocated_Event_Count = 196 200 0 ok 4 *** Failing SMART Attributes in /tmp/smart_finish_sdb *** ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 [color=red]050[/color] 050 [color=red]140[/color] Pre-fail Always FAILING_NOW 1195 0 sectors were pending re-allocation before the start of the preclear. 70 sectors are pending re-allocation at the end of the preclear, a change of 70 in the number of sectors pending re-allocation. 0 sectors had been re-allocated before the start of the preclear. 1195 sectors are re-allocated at the end of the preclear, a change of 1195 in the number of sectors re-allocated. [color=red]SMART overall-health status = FAILED![/color] RMA the drive. It has failed the pre-clear. It has major problems in reading the disk. Be very happy you did not install it in your server. The re-allocated sector value of 50 is below the failure-threshold for that parameter of 140. Joe L.

The first cycle does a pre-read, a write, and a post read. Subsequent consecutive cycles perform a "write" and a post-read. (They get to skip the pre-read since the post-read of the prior cycle acts as the pre-read for the next "write". ) This feature is new on recent versions of the pre-clear script. It used to always do the pre-read on every cycle when asked to perform multiple cycles and they all took the same time. So... the 8 hours difference is easily explained. It was the initial pre-read on the first cycle. Joe L.

no... not normal... Looks like the -p option is not being applied properly. You are probably better off just changing the value in the script by using these commands cd directory_where_you_unzipped_cache_dirs sed -i "s/^cache_pressure=10/cache_pressure=200/" cache_dirs I don't have the time to debug today.

Correct, but you'll need to include its full path /boot/cache_dirs -w -i "DVDd" (assuming you put it at the root of your flash drive) Yes, you can do exactly that. Again you'll either need to change directory to /boot to invoke it, or, use the full path to it. Yes it is current You probably do not need to do anything, but cache_dirs will set the cache_pressure to 10. (default is 100) There is an option to cache_dirs to set it as you please. Just add "-p 100" (or whatever you like) as an additional argument when you invoke it. /boot/cache_dirs -p 100 -w -i "DVDs"

Only the manufacturer knows how to interpret the "raw" results for most attributes. Read error rates especially. You and I use the "normalized" values. As long as they are above the affiliated failure threshold, they are fine. The faliure threshold is 006 You started out with a value of 100. It INCREASED from 100 (got better) when the first pre-clear and finished with a value of 118. It has the starting to average downward, now at 116, but still better than the factory initialized value of 100. Remember, it has to drop to 6 before the SMART firmware will consider the drive to have failed. Please download the newer preclear_disk.sh script. (Just posted a few days ago) as it has a much easier output format for less-experienced users such as yourself. Upgrading the disk firmware to fix a bug is usually a good idea. Drive manufacturers rarely issue updates unless their problems are very serious. Joe L.

I guess you just do not want to look for yourself. No, nothing wrong with the second disk at this time. Joe L.

Are there any sectors pending re-allocation? Are there any sectors already re-allocated? Are there any SMART parameters that are marked as FAILING_NOW? Are there any SMART parameters where the normalized VALUE is nearing the failure THRESHOLD? If you don't know what to look for, this might help. Joe L.

perfectly normal.

It depends. If that was from the smart report at the start of the preclear, then yes. If from the report at the end, I'd not trust it be accurate unless the drive, even though "used" was really not used, and the preclear took 23 hours.

That column will say "FAILING_NOW" if the current normalized VALUE is equal to or below the THRESH (threshold) for that parameter.

Yes, There are no re-allocated sectors, and none pending re-allocation, and no other parameter is "FAILING_NOW" (in the WHEN_FAILED) column.

Both disks look good. Both successfully cleared, no re-allocated sectors, no sectors pending re-allocation. Joe L.

There are no re-allocated sectors, or sectors pending re-allocation. No SMART paramter is FAILING_NOW as no normalized VALUE is at or below the failure THRESHOLD. Enjoy your new disk.

TERM=xterm also works.

The disk might have failed. The power or data connector might have come loose. If you get no output when you type sfdisk -g dev/sdb then there is nothing the preclear script can do to get it. you can try to power cycle the drive. (stop array, power down the server, and reboot)

When the raw-read error rate reaches the "failure threshold" of 6 you can worry. Right now, it is not even close. From what I can see the worst value was 099, so it has improved. I'd keep an eye on it but not be terribly concerned. Joe L.

Change the line with the test from PACKAGE_VERSION_TEST HandBrakeCLI -u 2>&1 | grep '^HandBrake' | awk '{print $2}' to PACKAGE_VERSION_TEST /usr/local/bin/HandBrakeCLI -u 2>&1 | grep '^HandBrake' | awk '{print $2}' /usr/local/bin is not in unMENU's search path. other than that, you did real well. Joe L.

It looks like it has stopped responding. You can try on the command line fdisk -l /dev/sdb It might have died an early death, or a connector to it might have come loose. It might wake-up after a power cycle. Be thankful if it did die when being tested. Far better than it dying after it holds all your files.

No, you have two "devices" /dev/sdd = the entire un-assigned drive from sector 0 to the end /dev/sdd1 = the first partition on the un-assigned drive. (the preclear script creates an empty first partition, starting at sector 63 of the drive) You can do it either way. It is your choice. Joe L.

Yes, the disk is responding once more.