Joe L.

What you posted is the second smart report loogged by the preclear process. It does not indicate if the process was successful or not. It is NOT the output of the preclear process, nor is it a full syslog. It shows a perfectly healthy drive For this thread, we would like the preclear output, not the syslog. In fact, it is not necessary to look at the syslog at all in most cases. You can find the preclear report in a "preclear_reports" directory on your flash drive. It will be named "preclear_rpt_(drive)_YYYY-MM-DD"

Look at the normalized values... they actually improved during the preclear. (they are further from their failure thresholds, and it looks as if they start at 100 when fresh from the factory, as that is the "old value" for most those that channged) Ignore the raw values... very few are meaningful to end users. Your drive got better as it broke in during the preclear.

It indicates you fat-fingered the command. /dev/sdboota does not exist. There is a utility that can be run on some hard disks.

Both disks cleared fine. SDB has a lot of load cycles, it seems to be parking its heads every few minutes.. That is a firmware option that apparently can be changed on some drives.

don't start it using "at". In other words, it is queuing itself to be started later since when you are starting it the array itself is not yet up and running.

I can almost guarantee that is the case.

for each drive, type: preclear_disk.sh -t dev/sdX where sdX = the three letter device name. It will tell you if the preclear signature is correct for that drive.

It was reported this time because the normalized value changed from 91 to 92. I did not look at it. You are welcome.

Since you did not attach a system log, I'll figure you need no other help in determining what is going on. It sounds like a bad disk, or bad communications with the disk. You'll need to look in your system log for the actual details. Typically, when running slowly, errors are being logged there.

Something is up with sda, as there should never be any sectors pending re-allocation at the end of the process unless it was discovered in the post-read, and that would indicate it was not written properly when zeroing the drive. Another pre-clear on it is in order. You'll need to look in the system log for clues why it took so long to clear /dev/sda. There could be lots of errors there on the disk controller that would not show on a smart report. The "-A" option asks that the pre-clear signature request a partition starting on sector 64, (aligned on a 4k boundary) Any disk will work perfectly with that alignment except for an EARS drive with a jumper added to force it to electrically add 1 to requested sectors. You'll need to post a system log to get any more analysis on /dev/sda, but start a new thread in the general support forum, as that is a performance issue, not a preclear one. Joe L.

it is all done in memory... so no files to delete to disable it. You can put a "#" at the start of the line in the "go" script to comment out the line from being executed.

Good feedback. I'll add more descriptive text. (I'll probably wait until there another change is needed before posting version 1.14, but you will see the added text then.) Joe L.

The -A and -a have absolutely no meaning or purpose on a drive with a size greater than 2.2TB. Even if you had supplied them, they would be ignored. Drives > 2.2TB use a GPT partition, not an MBR defined partition. The GPT partition is always created on a 4k boundary, regardless of what other options you may have set or selected. Enjoy your new drives.

The designations of the drives are assigned dynamically, even from one boot to another they can change. They are assigned as the linux kernel identifies then as they spin up and initialize. Go by the model/serial numbers. NEVER assume the same disk if all you are going by is sda, sdb, etc. It sounds as if you still have a disk.cfg file that points to the old disk config. What version of unRAID are you running? What version of the preclear script are you running? Type preclear_disk.sh -v to see the version. I'm using UnRaid 5.0 beta 11 and preclear version is 1.13. I am sure that sda, sdb etc. is not part of my array, so I know that is not the issue. Can you help me check the disk.cfg file. Thanks so much for your help. Sure. Use any editor you like, look at the files config/disk.cfg and /var/local/emhttp/disks.ini

The designations of the drives are assigned dynamically, even from one boot to another they can change. They are assigned as the linux kernel identifies then as they spin up and initialize. Go by the model/serial numbers. NEVER assume the same disk if all you are going by is sda, sdb, etc. It sounds as if you still have a disk.cfg file that points to the old disk config. What version of unRAID are you running? What version of the preclear script are you running? Type preclear_disk.sh -v to see the version.

Do you have windows set to show icons? That would mean windows is accessing the contents of the file, not just the directory entries. Joe L.

Joe, I don't see this as an unraid issue. I don't think I am making myself clear. Let me try again. You have logic in the cache_dirs script to stop caching when 'mover' is running. I don't believe that logic is stopping the caching in my situation. Whenever cache_dirs is running on my setup and the 'mover' script runs, I get the "duplicate object" log entries. I get them at night when 'mover' runs, and I get them also when I execute 'mover' manually. If I stop cache_dirs (cache_dirs -q), the log entries stop when 'mover' runs. Is there anything I can do to troubleshoot this? Looking in the code. It is basically looking once per loop for the file /var/run/mover.pid and if the process whose PID is in it is running, will wait until it is gone. If the mover starts while cache_dirs is in the middle of a scan, I can see how the duplicate object messages can occur. (They are sill a bug in unRAID... the log messages should not occur while mover is moving a file from cache) The messages should not continue though... not once it finishes a scan and loops where it will again test for the /var/run/mover.pid file.. However, the real cause was reported recently... http://lime-technology.com/forum/index.php?topic=4500.msg132162#msg132162 I was a typo... Corrected script now attached to the first post in this thread. Joe L.

OK.... I mis-understood. (or rather, I did not notice you said they only occurred when your "mover" was moving files to the protected array) While the file is being copied, it does exist on two disks... (the cache drive AND the parity protected data disk it is being copied to) In my opinion, the error message in the log should not occur under that move, and is a bug if it is occurring in reporting dupes. (that type of "duplicate object" should be expected and ignored while a file is being moved. No syslog entries should be made for them.) Please send a PM to limetech, or an email to [email protected] and report the bug. Joe L.

Any time you list the contents of the shares with the duplicate entries you will get the "duplicate object" messages in the log file if they exist. Basically, all cache_dirs is doing, is repeatedly listing the directories, to keep them in the most recently used disk buffer cache (or, more accurately, to keep them from being the least recently used and freed for other use.). To get rid of the duplicate object log entries, get rid of the duplicate objects. Joe L.

The disk looks perfect, but the time it took is probably about double than most. It probably indicates an issue with your disk controller or how it is configured in the BIOS (although it could also be affected by what else you were doing at the same time) Post your syslog. (before you reboot)

It would depend on how much memory you have. If you have less than 500 Meg, it might be. Joe L.

the includes and excludes cannot be used on sub-directories under a share as the code is written. You can exclude, or include "server" You can, of course modify the script to do as you desire, but that is not how I originally wrote it. I think you'll find a solution in this thread, since I remember a while ago someone asking a similar question. For the most part, unless you have a HUGE set of files (100000 or more) in a directory there is no need to use anything to include or exclude.

Linux uses slashes, dos uses back-slashes. If "server" is indeed a folder on your user shares (you have a user-share named "server") then the path is /server/MP3 not \server\MP3

make sure you give the full path to the command. If you're not sure, zip your go file and attach it, otherwise all we can say is it works for us. If you invoke it immediately after emhttp the array will not yet be online, so it should queue itself to be re-invoked.... (it you gave it the -w option when invoking it)

You have carriage returns at the ends of lines. You need to edit with an editor that does not add carriage returns. + timeout=$'15\r' + count=$'15\r'