Joe L.

What issues are you seeing in those reports? They look just fine to me, in fact, the raw-read-error rate IMPROVED on both drives from starting values of 100 to 112 and 114. Joe L.

SMART report looks fine. It's hard to say what the times should be for a 6tb drive, until other reports come in. Doesn't look wildly wrong though. You used Preclear 1.9, which is very old, probably too old for very large drives. I'm not sure you can trust the result on drives over 2TB using any Preclear less than 1.13, and perhaps Preclear 1.15 (the latest). You should definitely upgrade Preclear, and you may want to try it again. At least, try a Preclear -t test on it, with the latest Preclear. unRAID will NOT consider the disk pre-cleared. (the older version of the preclear script did not know how to properly create the preclear signature for disks over 2.2TB. ) A clue is that it says the partition starts on sector 64. That is completely WRONG for any disk over 2.2TB. Now, the disk did get zeroed, and does look good, but it does not contain a valid "protective" MBR starting on sector 1, nor a valid unRAID precleared signature. If you attempted to assign it to an array already protected by parity, unRAID will clear it again. (while the array is kept off-line) Joe l.

I'm sorry, but I have no idea what the plugin does, nor do I support it in any way. There is never a need to kill cache_dirs (at least with the version I wrote) It will suspend itself when the mover is run. Joe L.

I guess you did not take the time to read back a few posts: http://lime-technology.com/forum/index.php?topic=4068.msg317738#msg317738

You apparently typed /dev/sdG (with a capital "G") instead of /dev/sdg (all lower case) Basically, the preclear script said the device did not exist and exited. (Linux is case-sensitive.) Joe L.

I would guess you are running out of "low-memory" with all those applications running and cache_dirs too. Sounds like emhttp is being killed by the kernel in an attempt to free memory, since it was detected as being idle the longest. For most people, upgrading to 6.X is as simple as the new bzroot, bzimage. You'll probably also want the new syslinux.cfg to be able to boot to some of the new options. (The release notes for 6.X have the details on how to upgrade) Unfortunately, NONE of your existing plugins will work. They are 32 bit executables, and 6.X does not support them in any way. You need the 64 bit versions. Prior to upgrading, you'll need to disable/un-install the 32 bit versions, then after upgrading, you'll need to install and and configure their equivalent 64 bit versions. (I do not know if 64 bit plugin equivalents will exist yet for minidlna or servino that you've installed I've not been following those threads at all. Pretty sure they exist for most the others.) Joe L. Thanks Joe, very helpfull. I might move to V6 64bit. One question is important to me: Is there a 64bit version of of the apcupsd plugin or can it be configured through unmenu? I don't know which plugins are available in 64 bit versions, but I'll guess the most popular are. There is a 64 bit version of apcupsd available through unMENU. unMENU is 64 bit OS aware (as long as you use its "Check-for-updates/Install Updates" buttons on its user-scripts page and are running the more recent package-manager within it.). Once on a 64 bit OS, it will only show the 64 bit package versions of the packages it manages. There may also be a 4 bit apcupsd plugin... Again, I have not been following the 64 bit plugins activity as neither of my unRAID servers is running the 64 bit unRAID OS.

nothing to do with cache_dirs at all. The error messages are saying that the "ssl" package you are attempting to download does not exist on the server you are trying to download it from. Probably one of your plugins is attempting to download openssl for installation. You'll need to find an updated plugin, as the download URL in the ones you are attempting to load are out-of-date and no longer valid. Joe L.

I would guess you are running out of "low-memory" with all those applications running and cache_dirs too. Sounds like emhttp is being killed by the kernel in an attempt to free memory, since it was detected as being idle the longest. For most people, upgrading to 6.X is as simple as the new bzroot, bzimage. You'll probably also want the new syslinux.cfg to be able to boot to some of the new options. (The release notes for 6.X have the details on how to upgrade) Unfortunately, NONE of your existing plugins will work. They are 32 bit executables, and 6.X does not support them in any way. You need the 64 bit versions. Prior to upgrading, you'll need to disable/un-install the 32 bit versions, then after upgrading, you'll need to install and and configure their equivalent 64 bit versions. (I do not know if 64 bit plugin equivalents will exist yet for minidlna or servino that you've installed I've not been following those threads at all. Pretty sure they exist for most the others.) Joe L.

Exactly as the line above described. Changed attributes in files: /tmp/smart_start_sdc /tmp/smart_finish_sdc That attribute in your two smart reports (the one at the start of the preclear vs. the one at the finish) changed. The normalized value changed from 166 to 162. Probably as a result of the disk heating up while it was being used. The end-value of 37C is perfectly fine, so I doubt you have anything to do except to learn more about how to interpret smartctl reports. The see the actual lines, you would need to look in the to files listed: /tmp/smart_start_sdc /tmp/smart_finish_sdc Joe L.

nothing to worry about. "fdisk" is reporting about the fake "protective" partition that was defined to fool older utilities (such as "fdisk") into thinking the entire disk is allocated. The actual GPT partition does not start at sector 1.

agreed... at this point, I would never trust that drive. The pending sectors needs to be cleared, and stay cleared. (writing the zeros to the drive should re-allocate all the sectors, and it seems it is, as the count goes to zero after the write phase, but the subsequent "read" detects more un-readable sectors. ) Note: it could be a power supply issue... If the poor quality power induces errors on reading where the sector contents do not match the checksum at the end of the sector... or perhaps what is being written does not match that expected, so the checksum when read back is wrong and the sector marked as un-readable. Basically, unless you can get through several additional read/write cycles with NO sectors pending re-allocation, and since that drive seems to constantly detect additional un-readable sectors, it is a strong candidate for an RMA. Be thankful you found it before you used it for your data. As it is currently working, it would cause hair-loss. Joe L.

All you posted is the output of a smartctl report. It looks fine. What error are you seeing? Joe L. Oh. I thought the disk had errors. It was just listed on the final output. Things like Attribute NEW VAL OLD VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 118 101 6 OK 186259920 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-end_error = 100 100 99 near_thresh 0 Airflow_Temper_Cel = 66 69 45 near_thresh 34 Temper_Cel = 34 31 0 ok 34 I was worried about the near_threshold issues. Does it sort of mean the disk is not new if there are old smart attribtes? Sorry, this is really confusing! It indicates the current normalized value is close to the affiliated failure threshold set by that disks manufacturer. Nobody knows how the "raw" counts on those attributes equate to the normalized values, at they typically do not tell, but if we assume the normalized value will decrement by 1 every time the disk fails to spin up, then it would take three failures to spin up to get to the affiliated failure threshold of 97. To me, even one failure to spin up is an issue, so if you ever see that value increasing, keep an eye on it. HOWEVER, the starting value for spin-retry is 100, and there have been NO failures in the raw column, so the disk has never failed to spin-up. (a good thing) The "near_thresh" is just there to help you decide if you need to investigate further. If you are that interested, you really should learn hoe to interpret the full smartctl reports, and not the summary the preclear script gives to you in its attempt to show you the parameters that have changed in the before and after reports. basically, according to what I can see from that difference report, the disk is fine. Joe L.

All you posted is the output of a smartctl report. It looks fine. What error are you seeing? Joe L.

It is likely the disk just stopped responding at all. the script is attempting to interpret the output of the smartctl program and the output of the "dd" command. Obviously, the output is not what was expected. If you type smartctl -a /dev/sdX I doubt you'll get a report. Look for a loose cable, (or a dead drive) Joe L.

but for a lot of people all this does is make your unraid crash due to out of memory... Then the solution is simple... either have it cache less (by restricting the depth of the scan, or the restricting the shares it caches) or add more memory, or if running 32 bit unRAID, upgrade to 64 bit unRAID where low-memory is not limited. It has the options for just about any situation. On my older server it runs in 512 meg of ram... but I keep it out of the "data" directory and just run it on the "movies" and "music" shares. All the media I have is cached within the memory available. Joe L.

Glad you cleared up my confusion. I've attached a new updated version in the first post in this thread. Hopefully it will work for you. You can probably invoke it without any special options, but if it still causes issues with it setting the ulimit on your system (it sets it to 50000 now on a 64 bit OS) you can set it to anything you like with -U NNNNNNN Setting it to zero is special, in that case, no ulimit command is executed at all, you'll inherit the systems default setting. ( "cache_dirs -w -U 0" ) The new version is 64bit aware and also has the three lines near the top of the file (attempting to exec /bin/bash if $SHELL is not set ) removed. ( They were needed long ago in an older version of unRAID. ) Joe L.

I'm confused... You do not "start" cache_dirs with the "-q" option. That is how you "stop" a cache_dirs process that is already running. ( the -q option has it look for a file the running process had created containing its process ID, the "-q" process then kills that original process via the ID it found.) Cache_dirs in many cases DOES create one child process per mounted disk share. (unless you supply an argument to cache_dirs to NOT perform that function) These child processes are to purposely cause the mounted devices to be detected as "busy" when you attempt to stop the array. It then allows cache-dirs to detect those "busy" file-system messages and suspend itself when you are attempting to stop the array so the array can be stopped cleanly. The major issue people have had in the 64 bit world is the ulimit is set too low for many of them to fit their directory structure in memory. You can fix that issue by simply commenting out the lines in the script that set "ulimit". (or deleting them entirely) One person reported the newer version of the shell no longer sets $SHELL as /bin/sh when invoked as /bin/bash so therefore, cache_dirs could not be started from the "go" script. To fix that, delete the lines at the top of the script as shown in "red" here: #!/bin/bash if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then exec /bin/bash -c "$0" "$@" fi Joe L.

Have run the memory test 5 passes now, all OK. Next stop? I have two drives that did the same thing. I have upgrades to Unraid OS 5.0.5 - thinking maybe a compatibility issue between the OS and preclear 1.15 (5B15 and preclear 1.13 worked fine together for the 2TB drives I was using). With this upgrade, I plan to try pre clear again to see if it is that issue. Any other guidance appreciated. SH You can try, but the preclear script does absolutely nothing that the normal reading and writing of files would not do. I would suspect a hardware issue. If you have the same issue with two drives, and memory tests good, suspect the disk-controller, or power supply. (how many drives are attached? What capacity supply? How many 12 volt rails? )

A drive that returns different values than what was written to it is a real pain in the neck. It could be a bad drive, it could be a poorly regulated power supply line to the drive, it could be a bad disk controller, or even bad memory. I'd start with a memory test of the server, preferably overnight, or at least several passes to make sure it is not falsely leading you to think the disk is bad. Joe L.

Ouch... an unresponsive disk could be a real headache in an unRAID server. I'm unhappy it failed, but in the long term, for your data, you are better off RMA'ing int. Joe L.

yes, although the second disk had FAILED SMART IN THE PAST when the airflow temperature normalized value went below the affiliated failure threshold. You apparently baked that disk at one point? (was it in an external case with no fan?) You are also using an older version of the pre-clear script... A newer one has been released. (no need to re-do the pre-clear, yours went fine)

if it is unable to read the pre-clear signature it wrote, then either the disk is bad, or the disk controller is bad, or the disk just stopped responding meaning it is no longer working with your disk controller for some reason. (the "zero bytes copied" seems to indicate the latter) Does the disk then respond to a smartctl command? Or is it completely un-responsive? smartctl -A /dev/sdX Of course, it is possible for it to be something else... what version unRAID are you using? 32bit? or 64 bit? Joe L.

you'll have to let us know.... If the verify option of the preclear script shows it is OK, odds are you'll be fine. You've basically used two different SATA controllers, and the one reported a slightly different size. try preclear_disk.sh -t /dev/sdX and see what it says. Since the math used by the preclear script when verifying a signature is the same as used by unRAID, if it says it is precleared, odds are good unRAID will think so too.

Looks great. No sectors re-allocated or pending re-allocation. Reassign the new disk as your parity disk, let it compute parity... Then, perform a parity check. (That will prove you can read the parity bytes you stored) Only then should you move any other drives. Joe L.

You do not need to, BUT, you should, as you said, to test the drive and to get past the early part of the "bathtub curve" About 1 in 5 drives seems to fail initially or in the first hours of operation. Do you feel lucky? Yes, the drive is completely written, but it is not read until you perform a subsequent parity check. You will not know of un-readable sectors until after you've performed those two steps. After the subsequent parity check you can get a SMART report. If you see any sectors pending re-allocation it is necessary to write again to the sectors marked as un-readable. This will either make them readable, or cause the SMART firmware to re-allocate them. Then you'll again need to perform another parity check to see if the re-allocations were all successful and readable after being re-allocated. Sounds like a lot of reading and writing... It is... and that is almost exactly what the preclear script does for you. Joe L.