Joe L.

Looks very interesting... can you perform a smartctl -a -d ata /dev/??? on your disk that reported a 40% rating? I'd love to see what they consider in their evaluation.

That would seem to indicate that the current directory is not part of the search path. Therefore, even when "cd'ing" into the directory with the program, it was not found, since it was not in the search path. You can probably fix that by adding two lines, somewhere above the lines for the add-ons: PATH=$PATH:. export PATH

You must use "echo" if you are using "at" as it expects the command to be run as its standard input. The quotes around the script name are not needed as there are no special characters. Joe L.

You can ignore the error, unRAID has no mail command , therefore "at" cannot mail to you the fact the command was started.

Yes, a diff would show you all the changes... But let's say the "raw" value of a given did not change (or is blank as with so many attributes), and let's say the CURRENT, WORST, or THRESHOLD did not change. Let's also say the CURRENT value for that attribute has reached the THRESHOLD. The "Failing" column for that attribute in the "pre" report would say "FAILING_NOW" and it would "FAILING_NOW" in the "post" report, therefor the line for that attribute would not show in the "diff" The odds of this happening and the disk still be able to be cleared are slim, but it could happen. Joe L.

You would look for failing attributes that were unchanged between the pre and post reports (and would therefore not show in the diff). You drive looks fine.

Exactly. But you should look at the full smart report to be absolutely certain. They were logged in your syslog. Enjoy your new disk drive.

On the target machine run find /mnt/disk* -depth -type d -empty -delete

There is a logic flaw with the program. (and you are correct, the two tests had nothing to do with each other) The program will NOT properly detect a on-line device with a "ping" command if there is more than one device in the list. Here is an experiment illustrating the issue, all typed on the command line: pingIPs="192.168.2.21 192.168.2.31" for i in "$pingIPs"; do echo ping -c1 $i; done ping -c1 192.168.2.21 192.168.2.31 Notice I simply printed what would be occurring. Notice only one "ping" command was executed, and with the argument of both IP addresses. (It would fail as bad syntax) The error is occurring because the "for" loop is being invoked incorrectly. It should not have quote marks around $pingIPs. Here is a second try with the correct syntax. Notice no quote marks around $pingIPs: for i in $pingIPs; do echo ping -c1 $i; done ping -c1 192.168.2.21 ping -c1 192.168.2.31 The fix is simple, change the for loop in the check_IP_status function from: for i in "$pingIPs" to for i in $pingIPs deleting the quote marks. The program would work perfectly if you only had one IP address in the $pingIPs variable even with the quotes, but fail if you had more than one device defined. Joe L.

That's what I get for not running it myself... I don't think my MB supports S3 sleep...

Yes, you do need to set the line to have it check the TCP/IP activity. So, set the IP addresses AND set # control of external timeout checkTCP=$yes # check for TCP activity

It the server is not shutting down when you are watching movies, then the bwm-ng is probably working just fine. If the server is shutting down when not watching movies, but when your media players are online, then either: 1. You did not edit the line in the script to hold the IP addresses of your media players or 2. Your media players do not respond to a ping command The line in the script to be edited is: pingIPs="192.168.1.40 192.168.1.45" # do not sleep if <$pingsIPs> are pingable The IP addresses there must be those of your media payers. If they are, then you can test if they respond to a "ping" by typing: ping -c 5 xxx.xxx.xxx.xxx using the IP address of each media server. Joe L.

these numbers represent the differences between the SMART report before the pre-clear cycle and after. The disk could have a parameter that is FAILING before, and equally FAILING after, and if the parameters involved did not change their counts, would not show in the "diff" report. with that in mind, it is highly unlikely, and still be able to clear a drive, but it could happen. as far as the various numbers, you need to only worry about a few parameters... those representing sectors marked for re-allocation, and those already re-allocated. Other than those two, unless a parameter shows "FAILED" or "FAILING_NOW" where the "-" on your printout of the "diff" exists, you are OK. The current "normalized" read error rate is 108, prior to the preclear, it was 117. The worst ever measured over the lifetime of the drive was "99" The failure threshold is "006" If the normalized read error rate goes BELOW "006" then the drive is considered to be failing. All drives have internal read errors. They are all designed to re-read on an error. As long as the normalized error rate is above the threshold, you are fine. Nobody except the manufacturer knows how to interpret the "raw" values in the right-most column (and they don't tell anybody) The same goes for your "seek error rate" The threshold is "030" the current value (both pre and post) is "060" and the worst value ever "056." the raw values are again only meaningful to the manufacturer. The "high fly writes" seem to have incremented by 1 in the raw value... again, the normalized value of "099" is nowhere near the failure threshold of "000" About the only parameter that has a raw value that is understandable is the temperature. Apparently, during the pre-clear process the drive reached a new "max" temperature of 26C. Enjoy your new drive... I know the pre-clear script needs to be better in explaining the output, but when I wrote it I figured the difference were most interesting. Turns out most are not very useful at all unless you detect a rapid trend towards the "normalized" failure threshold. Joe L.

The parity check is only normal if you did not stop the array cleanly before rebooting. You might want to post a syslog. If you think you stopped the array before rebooting, and the parity check was unexpected, then you might want to post a syslog to see if there was a different reason for the parity check. Joe L. That explains it then. I did not stop the array via the web interface. I only pressed the Reset button on my MD-1510. Thanks! Don't know how to say this any other way, but don't just hit the reset button unless absolutely necessary and you have no way to reboot otherwise. It might cause you to lose data... if the files being written to disks had not yet been flushed from the disk buffer cache to the physical disks they might be mangled/partially written, or lost/never written. Always stop the array first using the "Stop" button on the web-interface. Then you can reset/reboot/power down as needed. When you power back up, the array will know it shut down cleanly and not need to perform a full parity check. Joe L.

The parity check is only normal if you did not stop the array cleanly before rebooting. You might want to post a syslog. If you think you stopped the array before rebooting, and the parity check was unexpected, then you might want to post a syslog to see if there was a different reason for the parity check. Joe L.

A lot will depend on how many files & folders you have... basically, you are now doing a "find" on twice as many. It might even be worse, as the entries from the disk shares you want to stay in the cache, to keep them from spinning down, might be displaced by the extra ones read by scanning the user share's twin copies.

It would be used for Experimentation only. User-shares are in memory already. No need to cache since access is quick regardless. It was made an option since user-shares are not "cached" specifically by cache_dirs by default. When we were first trying to identify what we needed to do to keep from spinning up a disk some thought the user-shares mith need to be cached too. They are not unless you use the -u option, but access is fast regardless. If you have a lot of ram you can experiment with using the -u option or not. General opinion is it will not make a difference (other than to cause the CPU to do more work). Joe L.

I would like to suggest to Joe that he add a little normalization to these line comparisons. If the value(s) in the VALUE or WORST columns are 200 or 253, then replace them with 100, and then compare them (but keep the original for display). This will eliminate some confusion, since these are not actually SMART value changes, just initializations. The only extremely remote case where this may not work as expected is with a few older Maxtor drives, that actually use a scale from 253 down to 1, but I don't think this would matter. All others are scaled from either 200 or 100. I would also suggest dropping the 240's and perhaps others, or at least find a way to 'deprecate' them, so if they exist and are different, are not given any significance. I've been thinking on how to improve the report... it clearly is confusing too many. I'm thinking of only extracting the reallocated sectors and changes in the error logging area unless a measurement is actually FAILING. Problem is, experienced users will want to see more.

Easiest would be to add a line like this to your "sleep" script to move files from the cache drive before going to sleep. then, it does not matter if the server is sleeping at 3 am. If there are no files to move from cache, the "mover" script will take only a fraction of a second to run and the server will go to sleep immediately. If there are files to move, the server will move them and then go to sleep. # Do pre-sleep activities /usr/local/sbin/mover <-- new line to move files off of cache. # Go to sleep echo 3 > /proc/acpi/sleep <-- existing line to put server to sleep Joe L.

You are the first person I've read about who has run as long a test. 280 hours is a pretty decent burn in period..(nearly 12 days). Odds are you'll uncover any marginal hardware issues. Good luck. Sounds like you have a good handle on how to interpret the results. Joe L.

They are not spun down unless you do it yourself. Furthermore, on some disks, their firmware to spin down does not work, even if you do set it. (It is why unRAID has its own timers and spin-down logic) You can use the "-S nnn" option to hdparm to try to set the spin-down timer on a hard drive. If you are lucky, it will work. For the disks outside of the array, for a 1 hour spindown time, you can try hdparm -S 242 /dev/XXX where XXX = device name (sda, sdb, hda, hdb, etc...) Joe L.

fuser is a snapshot in time. If at that instant in time no access was occurring, then nothing will show. It is not able to show you things that happened 10 minutes ago and lasted a fraction of a second as a directory or file was accessed.. For that, we need something that can track all file and directory accesses, and log all of them.

I'm running the same versions. I only cache three levels deep. I only have 512 meg of RAM in my server and under 5000 files in my Movies and Music folders. You have lots more files you are attempting to cache, but far more memory too. Yes, it is normal to see two processes. part of the script is run in a sub-shell. (The while loop is run as a sub-shell)

I've got no idea... One difference I can think of is the search PATH used for commands might be different. (Causing the shell to traverse different directories when looking for the commands to run) My cache_dirs lives in /boot/custom/bin. I invoke it like this in my "go" script. my drives spin down just fine. I add /boot/custom/bin to the execution path in the "go" script. (This is my whole "go" script.) #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & PATH=$PATH:/boot/custom/bin cache_dirs -w -e Pictures -e data -d 3 fromdos < /boot/custom/bin/powerdown > /sbin/powerdown chmod u+x /sbin/powerdown fromdos < /boot/custom/etc/rc.d/S30-inittab-powerdown | sh fromdos < /boot/custom/etc/rc.d/rc.local_startup | sh echo "/boot/unmenu/uu" | at now + 1 minute What version of cache_dirs are you running? What version of unRAID are you running? Other than that, something is either 1. Accessing the disks, keeping them spinning or 2. Not finding the needed directory information in the buffer cache, so it has to spin up a drive to get the data. or 3. Your observation, although true, might have nothing to do with the actual issue. It might be something entirely un-related to how you invoke it.

Starting with "/" Wrong... it spports extended memory addressing, so you can add the additional memory. It is never supposed to terminate...it is supposed to loop forever. That is the whole idea, to keep accessing directory listing data to keep it in memory so it never becomes the "least-recently-accessed" data and becomes available for re-use. If you use a "-i" option it will NEVER cache anything but directories under "Test" so do not use "-i" in combination with -e the way you illustrated. For you, just invoke with -e Archive -w If you wish to see what is being cached, type find /mnt/disk* -maxdepth 3 -noleaf -print