Joe L.

looks great.

So we need to turn cache_dirs into a (semi-)plugin, starting it on one of the emhttp events? I've not needed to, but apparently some people do... In any case, instructions on how to tie it to an event are here: http://lime-technology.com/forum/index.php?topic=26201.0 it is actually pretty easy.

Yes No, but you'll trust the disk more. (about 1 in 5 fail in the first hours of operation... do you feel lucky?) If the drive is less than 2.2TB, and NOT a WD-EARS drive with a jumper added, use -A only if an older <=2TB WD-EARS drive with the jumper added should you use "-a" Joe L.

With ANY drive over 2.2TB, both the -A and -a options are silently ignored. Use them as you like, but the disk MUST (and will) be partitioned with a GPT partition, and it will have a "protective" MBR partition installed starting on sector 1 to convince older utilities the disk is entirely allocated. Make sure you use the most current version of the preclear script. Older versions did not properly set the preclear signature on some versions of unRAID. You can type preclear_disk.sh -v to learn the version (current version as of this post is 1.15) Joe L.

Then do not start cache_dirs from your "go" file.

then don't do that ... It almost sounds as if the first time it goes looking for directories to subsequently scan, they are not yet there, so it subsequently scans nothing (but does it very quickly) I'd add a few lines like this AFTER invoking enhttp, but before doing anything else in the config/go file. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & #Wait for the md devices to come online. while [[ ${LOOP:=30} -gt 1 && ! -b /dev/md1 ]] do (( LOOP=LOOP-1 )) echo "Waiting for /dev/md1 to come online ($LOOP)" sleep 1 done sleep 5 /boot/cache_dirs -w

For it to be using 100% of a CPU it would need to be in a tight loop. That is not expected. You might want to run it in the foreground to see what it is doing on your server. kill the currently running process, run it with "-F -v" from the command line. Joe L.

it is what others have said has worked for them. You can also set the ulimit to whatever you like via a new "-U NNNNNNN" option. If you do not specify a -U value, the program will now detect if you are on the 64 bit OS and use the 30k value instead of the lower value used on the 32 bit OS. Joe L.

I know... ;) Now uploaded and attached to the first post in this thread. Joe L.

It appears as if the drive is no longer readable. You might have a loose cable. Stop your array, power down, re-seat the cables, and then try once more. Joe L.

I have not included his compiled module. It fixes the issue with unRAID 6.X. I have not had time to investigate the GPL requirements of distributing his compiled program, and I suspect it also requires distributing his source code which was based on "dd". Joe L.

As Tom mentioned to me. with NFS and the SHFS/USER share, FUSE let's go of internal file handle structures after a certain amount of time when unused. This is the reason for the NFS stale file handle issue that crops up on the user shares. then, it (-u) might be something to try if you use NFS.

no, that is why it (-u) is not enabled by default.

normally, /mnt/user/... is not scanned,since it is only in memory (and only in memory) if -u is used, it too is scanned in addition to /mnt/diskX/...

Looks good this time.

Assigning a drive to a server,even just briefly, will change the preclear signature to where it will no longer be recognized if you un-assign the drive and re-assign it at a later time to the same or a different server. You can use preclear_disk.sh -t /dev/sdX to test if a disk has a current/correct preclear signature.

Your disk is perfectly fine. Some initial values are put purposely close to their affiliated failure threshold by the manufacturer. Example: Even a few spin-up-failures (subsequently requiring a re-try) would indicate a mechanical issue with the drive. Therefore, the failure threshold is very close to the starting value for that parameter on that disk.

Since cache_dirs is just a shell script, it is basically doing this in your example: create a semaphore_file (it can be removed with "cache_dirs -q" to cause cache_dirs to stop) while semaphore_file_exists do s=current_time (to track how long it takes to perform the "find" command) find /mnt/disk1/Movies >/dev/null 2>/dev/null find /mnt/disk2/Movies >/dev/null 2>/dev/null find /mnt/disk3/Movies >/dev/null 2>/dev/null find /mnt/disk4/Movies >/dev/null 2>/dev/null f=finish_time_of_find d=duration sleep for X seconds based on calculated duration done If the shell had a memory leak, it could be the culprit as it loops. (although possible, it is more likely that something else has the memory leak, since so many others use the "shell" and typically it gets found/fixed by the linux community.) At one point (long ago) there was a limit on the number of child processes a shell could "fork." That was addressed long ago by using a sub-shell It could as easily be an issue in the kernel, or in the user-share file system. (although the user-shares are not normally being scanned by the "find"commands) In any case, a memory leak would would normally show as increased memory size of a given process. sorting as you have, by "M" should show the culprit. Joe L.

It shows there was probably nothing wrong with the drive at all. If the drive was at fault (with unreadable sectors)you would have had sectors pending re-allocation, or already re-allocated at the START of the preclear. Without a syslog showing the specific errors, nobody can even tell why the read-errors occurred,. Regardless, nobody can guess if the drive is safe to re-use. The preclear report looks perfectly fine.

basically, you ran out of memory.

rma it.

UNC = un-correctable media-error = un-readable sector (sector contents do not match affiliated checksum at end of sector) let the preclear continue.

Is it normal for the Post Read on all his drives to be nearly half the Preread and Zeroing speeds? Yes, perfectly normal .... it is in the post-read where the verification of written zeros is performed. That takes the additional time.

They all look great. Enjoy your server.

It indicates that many disk errors are occurring, and that the linux kernel does not know how to handle them, so it is probably resetting the disk controller each time and trying again. Other than a possible loose cable, I've no idea... but there are lots of other users with similar errors if you search on google for "disk cdb unhandled error" Yes, not good. Joe L.