Joe L.

It shows those directories are no longer in the buffer cache. If you've excluded "Backups" that is entirely expected. If not, then you just have a lot of files to scan and cache, and not enough RAM to hole it all in the buffer cache.

Sorry to say, but it will not be as much help, but you can give it a try anyways. Joe L.

Looks like a perfectly healthy drive.

you should be fine (unless it does eventually proceed)

yes

Correct. Nothing is wrong when the manufacturer puts the failure threshold very near to the starting value of the normalized value. Right. It is not a problem. You are welcome.

The only time cache_dirs will re-schedule itself is if it thinks the array has stopped. This is the logic involved: # If the array is now stopped, terminate cache_dirs and re-invoke later via "at" num_dirs=`find /mnt/disk[1-9]* -type d -maxdepth 0 -print 2>/dev/null|wc -l` if [ "$num_dirs" -eq 0 ] then if [ "$background" = "yes" ] then rm -f $lockfile echo scheduling via at $at_command | logger -t$program_name echo $at_command " 1>/dev/null 2>&1" | at now + 1 minute fi In other words, this command must be returning 0 (zero directories found) find /mnt/disk[1-9]* -type d -maxdepth 0 -print | wc -l All I can think of is you are running into some system issue that prevents the above line from returning the number of directories. Try running it when the problem is occurring.

Your disks looked perfectly normal to me. Except, maybe, the Read performance--it's too fast . Specifically, the Pre Read Time speed. 209 MB/s as an AVERAGE for the entire drive, is fantastic. I'd have expected something closer to 150-160. "There's something going on here, but I don't know what it is ..." Ideas? Since he had run multiple cycles, the odds are some of what was "read" was from the linux buffer cache and not from the physical disk. (it would skew the speed calcs a bit towards the high side) Even so, that could only be a few GB, so it is impressive.

As suggested, I added what to look for into the thread where you downloaded the preclear script.

For the most part you are looking for ANY individual parameter that is FAILING_NOW (that would be bad) And, you are looking for re-allocated sectors, or sectors pending re-allocation. The "raw" counts on those columns are actual counts. The "raw" column on many parameters is meaningful to only the manufacturer. Do not worry if you see raw read errors, ALL drives have them, some report them, some do not. If you see the "normalized" value changing in value and getting closer to the affiliated error threshold, be attentive to the rate of change. Exception are those parameters where the failure threshold is only a few counts from the initial starting value. (spin-up-retry failure is often set very close to the initial value, as only a few failures to spin up to speed indicates a drive that is pending a possible complete failure) Many manufacturers have factory starting values of 253, and change to 100 or 200 once the drive has a few hours on it. This is perfectly normal. Any sectors pending re-allocation AFTER a preclear are particularly bad. Any un-readable sectors identified in the pre-read phase should have been re-allocated in the zeroing (writing) phase. Any remaining after the preclear would have been identified in the post-read phase. (indicating what was written could not be read back) An additional pre-clear should be performed, and if the numbers do not stabilize (additional non-readable sectors are found) then the disk should be returned as defective. Your disks looked perfectly normal to me. Joe L.

According to SMART, if the normalized value (in this case 60) is above the failure threshold (30) the disk is healthy. I'd keep an eye on the drive and see if the normalized value increases, or decreases over time. It might be that it will improve over time as it breaks in... If the normalized value continues to drop towards 30 in the next few months, then you might want to replace it. The two disks may be running different firmware. the first started at 253. The second (apparently) at 100. (unless that is the pre-process current normalized value vs. the post-process normalized value, in which case I'm wrong and in need of a second cup of coffee) Joe L.

All modern disks lie about their geometry. You can ignore what it says. There is absolutely no way the disk has that many heads, nor a fixed number of cylinders per track. The actual geometry has a variable number of sectors per track, and only a few disk heads. Joe L.

SimpleFeatures is just a "skin" for the stock unRAID management pages. You can use the "Format" button on it.

No, not at all, unMENU works with any version of unRAID (Although I'm not sure if it was ever tested in the 3.X series, but it was created in 2008, so it might have been) in fact, unMENU recently underwent a major appearance upgrade..it now supports .css skinning, with the ability to have selectable horizontal or vertical menus. See here: http://lime-technology.com/forum/index.php?topic=27051.0

mailx can be installed through unMENU's package manager. It also installs ssmtp, so that might clobber your SimpleFeatures install. You might need a different solution. Sorry, SimpleFeatures might look better, but in some cases,not as complete as the unMENU equivalents. Perhaps somebody has created a mailx plugin.

Yes, reading the first line of the error message...(at the very top of the usage output) error: "mail" program does not exist. SimpleFeatures does not install a "mail" program. Sorry... but "ssmtp" is not a replacement for "mail" "ssmtp" is used in combination with "mail". For "mail" to work properly with "cron" it must be an executable, not a shell script. It is why I installl and use mailx, so I can get the errors from cron. Joe L.

It indicates that either the preclear_disk.sh is corrupted, OR, you have programs missing on your server it is expecting to use. You should have none of the "command not found" or "syntax error" messages. did you open the preclear_disk.sh script in an editor? (possibly accidentally add carriage returns to the ends of the lines?) Another possibility is you ran out of memory for all you were running. Look in your syslog for out-of-memory (oom) errors. Unless you used the -r -w and -b options of the preclear script, three simultaneous preclears of large drives will likely run out of memory. I do not see anything unusual either, other than your disk's way of reporting its temperature. (and that does not harm anything) Joe L.

It indicates that either the preclear_disk.sh is corrupted, OR, you have programs missing on your server it is expecting to use. You should have none of the "command not found" or "syntax error" messages. did you open the preclear_disk.sh script in an editor? (possibly accidentally add carriage returns to the ends of the lines?) Another possibility is you ran out of memory for all you were running. Look in your syslog for out-of-memory (oom) errors. Unless you used the -r -w and -b options of the preclear script, three simultaneous preclears of large drives will likely run out of memory.

It indicates that either the preclear_disk.sh is corrupted, OR, you have programs missing on your server it is expecting to use. You should have none of the "command not found" or "syntax error" messages. did you open the preclear_disk.sh script in an editor? (possibly accidentally add carriage returns to the ends of the lines?)

Your manufacturer of your disk has set the failure threshold for those two parameters to value very close to the initial starting normalized values. Basically, there has never been an error, but if your disk ever has an issue in spinning up (possibly thee failures?) the disk will be considered as failing. The "end-to-end" failure is (I think) the ability to write and subsequently read the disk. If that cannot occur, the disk will be considered failed. The manufacturer could have put the failure threshold at 50 and incremented the normalized value by 50 for each failure, and had the same result but they each impliment SMART in their own way, and they aren't telling anybody of the details. Enjoy your disk. It looks great. Joe L.

cache_dirs ONLY reads the directory entries. If your windows explorer is updating its thumbnail images, or looking at the contents of any file, you will see the disk spin up. Turn off those features in windows (fdisk in windows will often stop them ) and you'll see the spin-ups stop. Joe L. PS. Only kidding about reformatting your window's hard disk. It does stop the spin-ups though.

There is no significance to "60" it might be a value used by that model drive once it is in use. NORMALIZED values are not described by the manufactures other than if they are above the affiliated error-threshold, the disk is healthy. Manufacturers all set their own logic on how the RAW values are presented. Some are actual counts, others are not. As ab example, your power-on hours looks like an actual value 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 7 but head-flying hours is probably not an actual human-readable value. 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 11154030067719 Your disks look fine.

Apparently the hot-plug made the /boot/config/disk.cfg file unreadable OR, more likely, the device ID changed under /sys/devices/$id/block and therefore, the preclear script could not match the disks in the .cfg file with those under/sys/devices. Joe L.

The disk should have contained all zeros after being written with all zeros. The post-read phase (after writing the disk with zeros) read some non-zero bytes. The problem can be a bad disk, or bad memory on the MB, or a bad disk controller, or a insufficient power supply. (poor cabling, too many splitters, poor connections to the drive rack, etc) you are lucky to find this before putting the disk in your array and you should try to figure out the actual cause, if you do not, you'll get constant odd parity errors and be unable to figure out which disk (if a disk) is causing them, since it could be nearly anything except the "mouse" that is causing them. One good thing... you can now have some condolence that perhaps one or more of the crashes or loss of data on your windows box might not have been caused by the coding at Microsoft. 8) You can try to prove it is the disk, or not... at the least, run a full memory test on your server, as it might be bad RAM (or ram not configured properly, bad timing, bad voltage, or wrong clock speed) Joe L.

You are misreading the smartctl report. EVERY parameter is in one of two categories. It is either an indicator that will increase over time (old age) or one that is an indication of a potential failure (pre-fail) If the "Normalized" value is at or lower than the affiliated "threshold" that that parameter "fails", otherwise, it passes. All your smart parameters pass. In some cases, the "raw" value can be interpreted as an actual count. In others, it cannot. As an example, the Power-off-retract count looks like an actual count. You've powered off the PC that drive was in 65 times while it was active. (when it still had the disk heads loaded) On the other hand, The "Head-Flying-Hours of 197637215095092 is not likely to be an actual count... A failure might just indicate the disk is getting older. Others might be an indication of an imminent failure.