Joe L.

Feb 17 10:26:25 unraid5 kernel: read_file: error 2 opening /boot/config/super.dat Feb 17 10:26:25 unraid5 kernel: md: could not read superblock from /boot/config/super.dat Your flash drive is not readable (and probably not writable) Run scandisk/checkdisk on it on your window's PC to fix it. Joe L.

The "svn" (non destructive) test will not destroy the preclear signature and will take less time (I think) The "svw" (write four values, ending with all zeros) will take longer, but is a more through test. It will need a subsequent preclear if you intend to add it as an additional disk in the array. If you intend to use it as a replacement of a failed/failing drive, the preclear signature is not necessary. If you have the time, this is the one I would perform. Depending on your needs, if you do wish to have a preclear signature you can skip the pre-read phase to save a bit of time since the badblocks would have just read all the sectors. To run only the writing of zeros and post-read-verify phases (skipping the pre--read) preclear_disk.sh -W -A /dev/sdk

I'd run a non-destructive read/write badblocks cycle on it. This will take many many many hours... It will read and then re-write every sector. badblocks -c 1024 -b 65536 -o /boot/badblocks_out.txt -svn /dev/sdk If anything will get it to settle down, it will. If you are absolutely certain of the device name of the disk AND IT IS NOT ASSIGNED TO YOUR ARRAY OR HOLD ANY DATA YOU WISH TO KEEP you can run the 4 pass badblocks write test on the disk. It will erase everything on the disk, including the preclear signature. This is a even longer test... (probably 80 hours or more on a 2TB drive) You will need to leave the telnet session open for this duration. (or you can run this under "screen", or on the system console) badblocks -c 1024 -b 65536 -o /boot/badblocks_out.txt -svw /dev/sdk Be absolutely certain you have the correct device name. It has no "are you sure" to prevent you from erasing the wrong drive. Joe L.

You are probably experiencing resource contention of some kind. They are probably each waiting on some resource the other has. Since you did not attach a syslog, I can assume you've already looked there for clues and found nothing. 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.