Joe L.

It is not "preclear" that identified the sectors, it is the SMART firmware during the post-read phase that did. They are now pending re-allocation when next written. If they had been identified in the pre-read phase, they would have been re-alocated when written with zeros in the "write" phase. Sectors pending re-allocation after a preclear are not a great sign. It indicates the drive should be cleared once more and if the sectors are not re-allocated, an RMA is as likely as anything in the future. There is a possibility that the power supply cannot keep up with the drive's demands during the "writing" phase, in which case, a replacement drive could potentially work the same. Your power supply is a single rail supply rated at 44Amps. It should be plenty powerful. However, if you have lots of splitters in between it and the drives, you might have poor voltages at the drives. Joe L.

Ah, thanks for the clarification. If thats the case, if the drive is not empty, would that slow it down? I didn't specify last time -- but it is not connected through USB Thanks for your help. Its OK, there are thousands of things you did not specify that would affect the answers I did not give you. Let's start simple here: http://lime-technology.com/forum/index.php?topic=9880.0 The preclear process does not read files, or file systems, it reads the raw disk. It does not care if the disk is full or empty, formatted or not. if it is slow, then either the interface to the disk is having errors, or the disk is having errors, or something entirely else. Since I'm not clairvoyant, and neither is anyone else reading this forum, nobody can give you the answers if you elect to keep information to yourself. You mentioned USB connections in your prior post. Just how do you have the drive connected? Most drives can be read at between 50 and 150MB/s. If yours is slower, it is either a older/slower drive, or connected incorrectly, or defective. Joe L.

looks really good to me.

If through a USB connection, it would not surprise me for it to be slow. As far as how it was previously formatted, it makes absolutely no difference at all to the preclear script. It is reading raw disk blocks, not the file-system. The preclear script does not "format" the drive. It zeroes the entire drive (after first reading it entirely to allow the drive's SMART firmware to locate unreadable sectors) and then writes the entire drive, then re-reads to ensure what was written can be read back. If all that completes, it writes in the first 512 bytes a signature that unRAID will recognize telling it the disk has been pre-cleared. After assigning the drive to the unRAID array it will then present to you a button to "Format" the drive. Only that button should be used to Format the drive as it will format it in a way unRAID will identify as one of its drives. Joe L.

I'm thinking it can, since to perform the test it has to evaluate the path /mnt/ then get the set of inodes (information nodes hold directory and file names) that define the directories under it, then see if one of them matches /mnt/user0 Those directory inodes are on the disks... and if not in the disk buffer cache will need to spin up the disk associated. That would potentially cause any disk under /mnt to spin up. You can just type mv /usr/local/sbin/mover /usr/local/sbin/mover.old to disable it. Have you tried using "inotifywatch" to see exactly what is being accessed? Joe L.

I'm thinking it can, since to perform the test it has to evaluate the path /mnt/ then get the set of inodes (information nodes hold directory and file names) that define the directories under it, then see if one of them matches /mnt/user0 Those directory inodes are on the disks... and if not in the disk buffer cache will need to spin up the disk associated. That would potentially cause any disk under /mnt to spin up. You can just type mv /usr/local/sbin/mover /usr/local/sbin/mover.old to disable it.

Unfortunately that disables all daily cron jobs. It would be better to examine /etc/cron.daily and determine what may be running that is causing the disk usage. Also, if cron was set to run daily jobs at 4:40am and your spindown delay is one hour, then the drives would spin down after 5:40am, not before that. What is your default spindown delay? If one hour, then it looks like something is running at 4:30am and accessing for several minutes Disk 3 and Disk 4, and once in a while Disk 2. It ran for 4 to 7 minutes last week, but only about 3 and a half minutes this week. It is not really a mystery Rob. The "mover" command on 4.7 invokes "sync" which will spin up all the drives. The "mover" command on 5.X is completely different in how it woks and does not invoke "sync" There is a unMENU package that when installed will add logic to the "mover" script on 4.7 that will cause it to only invoke "sync" if a file is actually moved. Joe L.

Try and have a spare (precleared) drive on hand. That 30+ hour wait time after one of your drives fails seems more like 60+. I just added a 3TB parity drive and now I need to keep a look out for a good deal on a shelf-spare. I like the idea of having a separate box to preclear drives and test plugins. Best of luck with your system! Cheers man, u too I'll try and grab a spare ASAP. Wanted to ask, are any of you guys per clearing through telnet, what happens when the session dies? the preclear process terminates when the session dies. You should use the system console, or invoke "screen" first, then invoke the preclear process within "screen" ... that way, if the session dies you can reconnect and the preclear process will not terminate with the session.

looks good to me too.

The limit is mostly the drive itself... aerial density of the platters combined with their rotational speed. As an example, your /dev/sdc apparently performed at an average read rate of 110MB/s You have 4194304 MB to read. 4194304 / 110 = 38130.0363636 seconds. 38130.0363636 seconds = 10.5916767677 hours... post-read might be improved a tiny bit, but only by writing a compiled program that can perform the verification. It will still be slower than the pre-read. I've elected to use a shell script that invokes native linux commands so it will run on any version of unRAID.

The pre-read throws away the contents of what is being read (sends it to /dev/null) Its whole purpose is to let the firmware on the disk identify un-readable sectors. The post-read verifies all that is being read is all zeros. (actually analyzes what is being read) It is normal for it to take longer because of that. Joe L.

yes.

No, it is just a shell script. that invokes the linux"find" command every few seconds. It can be killed off by the kernel if there is insufficient memory, but you would see evidence in the syslog.

Everything looks OK, but three values look inconsistent. 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 4505 (Misc) 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 1273 (Misc) 192 Power-Off_Retract_Count 0x0032 097 097 000 Old_age Always - 3712 (Misc) It seems to be saying that the drive has been power cycled 1273 times in the past, being spinning 4505 hours, but that the disk heads have been retraced as a result of an unexpected loss of power 3712 times. (as if the power connection was intermittent? ) Joe L.

There is no entry in unmenu's package manager for cache_dirs. It is a separate utility. The person who "borrowed" my code for cache_dirs and included it in their plugin did it without my explicit permission. (I wish they did not include my code, as it now confuses the user base.) It was me who updated the wiki today. The threads describing customization are still there, but moved later where there is less confusion. you must realize the program wen through a lot of changes and versions as we learned what worked and what did. Some of the wiki links were no longer best as they pointed to older versions. I know there is a plugin... ask the author for guidance on it. I have nothing to do with it or how to install it. I've never used it. I think it installs itself when you install the plugin. I've stayed away from the plugin system as it is NOWEHERE NEAR FINAL how it will work with unRAID. It is poorly implemented, there is no plugin manager, and more often than not, poorly created plugins either stop the array from stopping, or prevent it from starting. The entire "event" drive script is single threaded, and will stop the entire server from operating if any plugin misbehaves. It desperately needs a rewrite. It barely works... and as often as not, any issue stops the correct operation of the server starting/stopping. It is my intention, once there is a true plugin manager in 5.X, to possibly work on fixing the issues. I do not intend to sound off like this, so please accept my apology in advance. Frankly, I'm a bit offended by the statement in the plugin thread you linked to: To me, it is saying... I stoletook Joe's code, and included it in my plugin. If you have any issues, or want improvements, see Joe, as I have no idea what it does. For now, This thread http://lime-technology.com/forum/index.php?topic=4500.0 and this wiki entry http://www.lime-technology.com/wiki/index.php/Improving_unRAID_Performance#Keep_directory_entries_cached are most current. Joe L.

It is the command for MS-DOS, but not for linux/unix. The command for unMENU would be mkdir /boot/unmenu Apparently, you did not look here: http://code.google.com/p/unraid-unmenu/ or here http://lime-technology.com/forum/index.php?topic=5568.0 Both give the "mkdir" command. Which "wiki" page are you referring to. Since the wiki can be edited by anyone, it is impossible for me to know where you looked. It probably was not this one http://lime-technology.com/wiki/index.php/UnRAID_Add_Ons#UnMENU Joe L.

I'd give it a preclear cycle and see if the 5 un-readable sectors get fixed (or re-allocated) I suspect a power issue though possible to be the cause of the unreadable sectors, since 193 times the disk heads were retracted in a unexpected power loss to the drive. (of course, if the drive was in a windows box previously, and you just turned off the switch and did not stop it properly, then that might be the cause of the retractions, or if you lost power a lot in its lifetime while it was spinning) Joe L.

This drive is not off to a good start, with numerous bad sectors right off the bat. This drive wasn't drop-shipped to you, it was drop-kicked to you! You may want to *try* to capture a SMART report, but if you can't - RMA it. On the bright side, it's always good to find out these things *before* you trust your data to it. not normal for it to progress slowly. look in the syslog for errors (and clues to why it is not progressing) Joe L.

Joe, are you referring to the attachment on the first post (now v1.6.7) or the previous post where you attached 'spinup_when_accessed.zip' ? I don't see this issue addressed in the version notes: this refers to "cache_dirs" The version attached to the first post in this thread has the updated cache_dirs.zip. Basically, it just documents what was there all along, and fixes a bug that did exist if you used -p and -w in the same command line. If you never used -p, the bug did not affect you.

I just posted a new version of cache_dirs that documents (and fixes) the previously undocumented "-p" option that allows you to set the "cache_pressure" kernel tunable parameter via a command line option. It is attached to the first post in this thread. The new version is 1.6.7. Type cache_dirs -V to see your version number. You do not need to replace your existing version unless you plan on experimenting with the -p option. (and trying different cache_pressure tunable values) Joe L.

it should be PB Thanks. Corrected version of spinup_when_accessed.sh attached to prior post.

This is a new disk, and it appears there was a small region with sectors not correctly initialized. Perhaps there had been an electrical spike that scrambled them? I don't know. But the zeroing phase appears to have had no problems rewriting them, so they are correct now. Why not preclear the disk one more time, to reassure yourself that the disk is fine. I really doubt you will see any further issues with this disk. Ok, i cleared it one more time, I guess everything is allright now? (syslog attached) There were no un-readable sectors this time. ( a good thing) Joe L.

How would it anticipate a file being opened? I use a different script that uses "lsof" to detect open files anticipating access. It works pretty well for me. spinup_when_accessed.sh It tracks activity browsing directories and spins up the affiliated drives. The script works by using lsof on /mnt/user to find the files and folders being accessed and then gets a list of the disks with the same top level folders (the user-shares) and then spins up the affiliated disks if they are not currently spinning. As soon as one of my media players performs a directory listing, or accesses a file, the affiliated drives are spun up. When I press "Play" the drives are ready and the media player does not time-out. A copy of the script is attached. type spinup_when_accessed.sh -? to see the usage help. Edit: fixed reported bug creating file named "0" on flash drive. New version attached. New version number is 1.4 type spinup_when_accessed.sh -v to see version number. Joe L. spinup_when_accessed.zip

I guess this happens because i rebooted, so there is still a line 'kernel: mdcmd (11): stop' in the syslog The script does work when I use `/usr/bin/cache_dirs -d 5 -m 3 -M 5 -w -F -B`. Any suggestions on how to fix this? Only one. Apparently your version of slackware is using a different version of the "bash" shell (or you are using a different shell entirely) and the disown %% command is not recognized. This would exhibit exactly the symptoms you described. So, if not using "bash", use it. If using a different version of the "bash" shell, change to one with a working "disown" command. If your environment does not have the $SHELL variable set, set it to /bin/bash before invoking the script. If your version of "bash" is not in /bin/bash, make a link for it there, or modify the first few lines in the script to where it lives on your system. Joe L.

You have more than enough free memory... It could be that something is trying to read more than just your directory content (windows explorer is notorious in that respect)... Possibly related: even WITH cache_dirs installed, viewing directories with Windows Explorer on an unRAID server would cause disks to spin up. Not so using Total Commander. That is usually because Window's Explorer opens up the files themselves so it can present thumbnail images to you. cache_dirs does not help with caching the contents of the files themselves.