Joe L.

I get Error (403) It seems you don't belong here! Hint: if you make it difficult for us to get to the preclear reports, we are not as likely to perform an analysis. Just zip them up and attach them to your next post. They are in your /boot/preclear_reports directory.

no, they look great. Probably... only time will tell.

yes, yes. -A (and 4k-aligned setting) only apply to disks < 2.2TB. They are both silently ignored on disks > 2.2TB.

You must be using an older version of the preclear script. The newer version of the preclear script explains that disks over 2.2TB will ALWAYS have a "protective" MBR entry made so it looks like the partition starts on sector 1 to keep legacy utilities thinking the disk is fully utilized. The "-a" or "-A" is ALWAYS silently ignored on disks > 2.2TB. They are meaningless with disks over 2.2TB. The actual GPT partition used on disks over 2.2TB IS always aligned on a 4k boundary. Oh yes, you should always get the newest version of the preclear script... No need to re-start, the newer version allows it to properly detect assigned disks if you've not yet started the array (to prevent you from accidentally clearing the wrong disk) It has the improved wording describing the partition it will create. Neither affects the actual preclear. Joe L.

poor power, loose cable, defective drive?

simple, apparently the disk stopped responding. The last "dd" showed 0 bytes read.

Yes.

What version of the preclear script are you running? 1.13. how do I update it if it's not the latest?Download and replace it with the newer version. (newest at this time=1.14) 3TB ALL disks > 2.2TB use GPT partitions. They are always properly aligned on a 4k boundary. The "-a" or "-A" options are silently ignored if used. MBR 4K alignedThat setting is used if disks are <= 2.2TB in the absence of an overriding "-a" option to the preclear script. Thanks for the help You are welcome.

We cannot tell. What version of the preclear script are you running? What size disk is being cleared? How do you have your preferred alignment setting set? (Settings->Disk Settings->Default partition format) Only by having those answers can your question be given an answer.

everything looks great... enjoy your new drives.

Your options are to determine WHY the writes failed. It could be anything from a bad/loose/intermittent cable/splitter/connector/drive-tray/back-plane to a bad/intermittent disk drive. Joe L.

You are not understanding how it works... cache_dirs does nothing except perform the equivalent of doing a "search" on your directories for all the files and throwing away the resulting file list to /dev/null. The very act of traversing the file-system tree puts those disk blocks into the disk buffer cache. The only thing cache_dirs does is repeat the search every few seconds so the most frequently accessed disk blocks do not "age" out of the disk buffer cache. To see what it does, kill it and re-run it in the foreground instead of in the background. ./cache_dirs -q ./cache_dirs -F -v The -m and -M are automatically set by cache_dirs. There is no need to use them unless you find the default is not working for you. The -w option is needed only if you invoke cache_dirs while the array is off-line. It will then have cache_dirs wait for the array to be on-line before starting a scan of the directory tree. Therefore, if the array is started, it is not needed either. -F = foreground -v = more verbose output.

If the disk stops responding (dos not even respond to an fdisk command) then you can't really do much. It could be the disk controller, the power supply, or anything connecting the drive to the MB. You seem to have eliminated the drive itself. (how many drives are you using? ) What SPECIFIC make/model power supply? How many splitters on the power cables are you using? , are you using drive trays?

So what's the corrective action? Reboot the server? . or add swap space, or free memory (kill memory hogs)

I checked my free memory and could not find anything wrong because there should be more than 3GB still be free (4GB installed in total) Any idea? When i used Cache dirs under Simplefeatures it worked without any problems, but Simple Features was bit buggy the so i had to delete it. The "find" command was apparently trying to allocate a contiguous chunk of memory of that size, which you apparently did not have. Your memory, although free, was fragmented.

The cache_dirs program will re-schedule itself when it finds no mounted disks. (Or thinks there are no mounted disks) It uses this command: find /mnt/disk[1-9]* -type d -maxdepth 0 -print If the number of lines returned is 0 (regardless of the reason the "find" failed) then it simply re-schedules itself for 1 minute later. It should return one line per disk. You could be out of memory.... Try the "find" command on your own when this is occurring...

give the full path to mysqladmin. When invoked by emhttp it might not know where it is located.

If the array is off-line, cache_dirs will re-schedule itself to be run when the array is possibly online. The log entry is entirely normal when this ccurs.

All disks have raw-read-errors, some report them, some do not. The failure threshold of 006 for that parameter in SMART is not close to the current normalized value of 116, however the "worst" normalized value has been as low as 99, so I'd keep an eye on the disk over the next months/years. It looks great otherwise. 1 Raw_Read_Error_Rate 0x000f 116 099 006 Pre-fail Always - 105202000 The normalized value actually improved from 114 to 116 over the course of the preclear. That is a good sign.

In the latest 5.X releases the array must be started for preclear to find the assigned disks. Yes, known issue with the latest unRAID. It use to keep a "readable" file with the disk assignments in the /boot/config folder, apparently, it no longer does. MAKE SURE YOU KNOW THE DISK YOU WILL BE CLEARING BY THE SERIAL NUMBER... Joe L.

I agree, the preclear script should do better in detecting the complete failure of a drive, it is not easy however, as the "dd" commands used do not always give clear indications of a failure. (preclear does not look in the syslog)

ALL disks have hardware error correction errors, some report them some do not. It is normal. The important thing to check is if the "normalized" value is above the affiliated error threshold. If it is, the drive is working as expected. All that said, the current normalized value is 031, the worst value it has been is 006, and the failure threshold is 0. Keep an eye on the disk, if the value continues to drop low into the single digits, it might be an indication of a drive nearing the end of its life. (it has been spinning for 16127 hours)

Hmmm, I wonder why it's doing it on my system? Thanks for checking it out! At least it gave me the opportunity to learn about tr (truncate)! tr = "translate"

Thanks Joe L. for writing! The link is the bottom of your original post in this thread, shown as cache_dirs.zip: http://lime-technology.com/forum/index.php?action=dlattach;topic=4500.0;attach=14315 I appreciate the help! Nothing at all wrong with the zip file. It has no ms-dos carriage returns in it. (I just downloaded it and un-zipped it on my server)

Not that I'm aware of... But which download link are you referring to?