Joe L.

As I recall, your collection is vastly larger than mine (with corresponding .jpg and .xml). How does your server manage it? Do you run across similar entries in your syslog? I don't attempt to get them to not spin up.

It probably indicates you have more total space in all the combined .jpg files on your server than can fit in the available buffer cache.

Hi Joe. Adding this line as suggested seems to constantly keep my disks spinning as it searches for the files. As far as I can tell, almost all disks (since the movies are spread across almost all disks) have not been spun down for three days since the reboot after changes have been made. Is this unusual or should it take a while? Also, my movies are note under one user share but split into several alphabetical bins (e.g. E-J, etc.). Is this the correct syntax to have to search all the Movie shares - find /mnt/user/Movies*? Thanks Joe! If your movies are not in a user-share named "Movies" then the sample command is the wrong syntax AND you will need to modify it. Easiest is to probably say something like: find /mnt/user/ -type f \( -name *.jpg -o -name *.xml \) -exec cat "{}" >/dev/null \; If your share names have spaces, or square braces, as you indicated, the user-share names might need to be quoted to eliminate the shell from expanding the names. Instead of adding the above line, type it on the command line, and see what it does. Instead of "-exec cat "{} >/dev/null \;" you can put find /mnt/user/ -type f \( -name *.jpg -o -name *.xml \) -print while you experiment with how to format the find commands.

Did you update unmenu to use the new MyMain? It should show: 07-unmenu-mymain.awk: 1.53 - changes for myMain 3-10-11 release, contributed by bjp999 - 5.0b6 support - Revision: 223 when you click on the "about" link. If you did, there is already one other person reporting it is not displaying their disk's pre-clear status. Might be the same bug. Joe L.

It hangs because unmenu is waiting for cache_dirs to return some output... which it will not because of the way it runs in the background. The post below your, or above mine as the case were, will work to start cache_dirs. I don't think that's accurate. When cache_dirs starts, it does output a string to the console. Looks like this on mine: cache_dirs process ID 5317 started, To terminate it, type: cache_dirs -q Further, I've now tried to invoke a script of mine that starts cache_dirs with my favorite arguments (that way it will always start with same arguments goth when called from go script and from unmenu). I've added an echo command - script looks like this: cache_dirs_args='-w -s -d 5 -e "Backup" -e "Games" -e "MP3BACKUP"' /boot/custom/cache_dirs/cache_dirs $cache_dirs_args echo "cache_dirs started in background with argsuments" $cache_dirs_args Still the same problem - unmenu hangs when I invoke my script (that I'm positively sure does output text). I can use the AT workarround (Thnx sacretagent), just curious as to why this happens with the way I had done it. Trying to learn here unMENU waits for all output. If you want it to return you must re-direct both standard output and error output from file descriptor 2. Try something like might work (I've not tried it): cache_dirs -w 2>&1 >/dev/null

Around line 476, add a line like the one in blue below (note, change the name of the user-share to match your share name. Mine is "Movies") Since my media player stores lots of information in .xml files, they too are cached by copying them to /dev/null): # always cache root dirs on each of the disks for i in /mnt/disk* /mnt/cache $user_share_dir do find $i -maxdepth 1 -noleaf >/dev/null 2>/dev/null done find /mnt/user/Movies -type f \( -name *.jpg -o -name *.xml \) -exec cat "{}" >/dev/null \; echo "$dir_list" | while read share_dir do for i in /mnt/disk* /mnt/cache $user_share_dir do # If the directory does not exist on this disk, don't do recursive "directory scan" [ ! -d "$i"/"$share_dir" ] && continue # Perform a recursive "find" on /mnt/disk??/share $command "$i"/"$share_dir" $args $depth >/dev/null 2>&1 [ $background = "no" -a $verbose = "yes" ] && echo "Executing $command $i/$share_dir $args $depth" done done

Unless the output report says they failed, or have re-allocated sectors, or sectors pending re-allocation, there is really nothing to look at. Enjoy your new drives. Joe L.

Before you started the pre-clear, there were 607 sectors that had been re-allocated. Typically that many would have people RMA the drive, even if it had not yet failed the SMART threshold. Before you started the pre-clear, there were 52 additional sectors pending re-allocation. During the zeroing of the drive, those 52 apparently were able to be re-written in pace rather than re-allocated, as the number of re-allocated sectors did not change. I'd run another pre-clear cycle. If nothing changes, use the drive but keep an eye on it. Or, RMA it... it is on its way to failing with over 600 sectors re-allocated.

Your "drill" in might be reading other files besides the directory entries. (scanning contents of files, displaying thumbnail images, etc) Those other files are not cached. The initial list of directories is just the top level directories. Use the "-F" option to put the cache_dirs in the foreground to watch as it does its scanning. It will help to understand what it is doing. Add the "-v" option to see even more detail when running in the foreground. If you find your media player is reading the .jpg or .xml files, you can add a line something like this in the loop just above line 472. find /mnt/user/Movies -type f \( -name *.jpg -o -name *.xml \) -exec cat "{}" >/dev/null \; It will read the contents of all the .jpg and .xml files and send the output to /dev/null. the side effect is that their contents is now in the disk buffer cache. Modify as needed with the name of your own "Movies" share. Joe L.

They should be fine. You were not trying to spin them all up at the same instant while preclearing.

If a read error occurs, all the drives are commanded to spin up simultaneously so the block being read can be re-constructed and returned back to the program requesting it. That will require the power supply to be able to spin up all the drives at the same time. The power supply on a large server is not the place to economize.

You do have an issue with air-flow. The disk in this report is a bit hotter than many consider safe at 46C. Most will advise you keep disk temperatures below 40C. Joe L.

You can use rsync now with the "-c command" option: -c command = use command instead of "find" ("command" should be quoted if it has embedded spaces)

Probably can detect the failure and try without the "-d ata" Not a bad idea for the next version. Thanks for the feedback.

That report is generated because the raw smart report is very difficult to interpert. The raw numbers are meaningless to anybody but the manufacturer. I know the thread is long, but it is because the disks are so important to us.

Nothing to worry about. Looks fine, but you used a very old version of the preclear script. You should get the newest one. Joe L.

My vote, RMA it, especially if brand new. At the very least, run several more prclear cycles on it and ONLY use the drive if no additional sectors are re-allocated or marked for re-allocation.

Some disk controllers do not like the default "-d ata" argumant passed to the smartctl command. The preclear_disk.sh program was unable to read the smart information therefor, that part of its output report is meaningless. You might be able to type: smartctl -a /dev/sdb and see if it will respond. If that works then you can use the "-D" option to the preclear_disk.sh script. preclear_disk.sh -D -M 4 /dev/sdb if not, you might be able to supply an alternate device type using the "-d" option: -D = disable "-d ata" used as argument to smartctl -d device_type = supply "-d device_type" to smartctl used to get device status This is not really an issue with the preclear script, but one with the smartctl program and your disk controller. Joe L.

If the drive is currently pre-cleared, and you did not do anything to it since, and have not yet assigned it to your array, you can use: preclear_disk.sh -C 64 /dev/sdX to convert it from a sector 63 start (not-aligned to 4k) to a sector 64 start (4k-aligned) in just a few seconds. (obviously, replace sdX with the correct three letter device name for your drive) You can just use the pre-clear again using the "-A" option and there is no need to zero out the MBR. The "-A" option will do that. However, that will take 25 tp 35 hours for another cycle.

malloc is a routine that allocates memory. Odds are you either ran out of free memory, or, you have some defective memory, or you used some parameters that asked it to allocate more memory than you have, or, the driver for your disk is buggy and did not free memory as it should have. Joe L.

The spin-up-time is only being listed because the current value is within 25 of its affiliated failure threshold. I've sen other disks where the failure threshold is 99 and the current value is 100. They too will have the attribute listed, even though nothing at all is wrong. If we do not know the starting "current" value for spin-up-time when the disk left the factory we'll not know if the current value is indicating it is taking longer to spin up, or acting perfectly normal. Best advice I can give is to compare that SMART attribute with other disks of the exact same manufacturer/make/model. If their current value is 100, or 200, then your disk might be taking longer than usual. Otherwise, just keep an eye on it by running an occasional SMART report on it.

The upgrade instructions are in the announcement thread, basically yes, but there is also a newer version of the memory test file to copy in place, so three files in total for you: Upgrading an existing Flash Device ---------------------------------- Note: after upgrading, some changes may require additional user intervention, please refer to the Change Log below. If you are currently running unRAID Server 4.6 or higher, please copy the following files from the new release to the root of your Flash device: bzimage bzroot If you are currently running unRAID Server 4.5.x, 4.4.x, 4.3.x or 4.2.x, please copy the following files from the new release to the root of your Flash device: bzimage bzroot memtest

take a screen shot of your config page and save a copy of your config folder and all its contents after you stop the array, but before you upgrade. rename the existing bzroot and bzimage files to bzroot.46 and bzimage.46, so it you need to revert it is as easy as re-naming them back and rebooting.

Near threshold is just an alert. I think I print that whenever the current value is within 75 of the failure threshold. For some disks/attributes, the factory initialized value is only a few counts, and sometimes only 1 greater than the affiliated failure threshold so the warning is always going to occur even though nothing at all is wrong. Joe L.