Joe L.

Nothing at all wrong with the drive. Joe L.

I'd say the disk is bad... I think 9168 is the highest number of re-allocated sectors I've ever seen on a disk without it being marked as failed. I'd strongly advise not using it in the unRAID array. 5 Reallocated_Sector_Ct 0x0033 087 087 036 Pre-fail Always - 9168

UNC media errors are sectors where the data on the sector does not match the checksum at the end of that sector. It might be a defective sector, or it might be written poorly. Either way, let the process complete. It will re-allocate the sector if it needs to when it gets to the writing phase, or, re-write it in place (it tries that first) in an attempt to not re-allocate the sector. Notice there were 39 sectors already re-allocated prior to the start of the process. Can't tell you about the time counters... Joe L.

No, there is no guarantee the manufacturer does what is needed. The risk is too high. So rather than risk someone's data, I have elected to not not add that option.

If you were using a physical timer/clock I would put it BETWEEN the wall outlet and the UPS. Then, set up unRAID to cleanly stop itself when power is lost while powered by the UPS (set it to power down after 15 seconds or so) Set it to power down the UPS too, so its batteries are not exhausted. Then, when timer is set to provide power back to the UPS, it will power up the server. That will work as long as you are able to cleanly stop all processes using the disks when powering down. Joe L.

It depends on your BIOS. Some BIOS have the ability turn on at a certain time, others do not. It entirely depends on your motherboard. As you said, you can set up a cron task to stop the array and power down. Joe L.

Looks fine. It had one sector which had been re-allocated before the start of the pre-clear, and no additional sectors were identified by the SMART firmware during the pre-clear. The drive should be fine. You are looking for sectors pending re-allocation and re-allocated sectors. (and changes in those parameters during the process) Most disks have anywhere from several hundred to several thousand spare sectors that can be used by the disks's SMART firmware to re-allocate un-readable sectors. Your disk is doing fine. Other than that, you are looking for ANY "normalized VALUE" parameter that has reached or fallen below the affiliated failure THRESHOLD. Joe L.

Looks fine. It had three sectors which had been re-allocated before the start of the pre-clear, and no additional sectors were identified by the SMART firmware during the pre-clear. The drive should be fine.

LOOKS GOOD TO ME.

A. it writes slower than it reads ? ? ? B. You are doing something else that is keeping the same disk controller busy ? ? ? C. Slow electrons ? ? ? D. Otherwise, no... you did NOT provide a syslog for analysis. (so all we can do is guess) did you look there for any signs of errors?

Looks fine. Enjoy your new drive.

I did consider cases like this when I added that "-d type" option. You are one of the first to report they were able to use it on their hardware. Very nice disk controller card... (very expensive too, but I assume it was something you already had) I'm guessing your hardware is far more than a usual desktop machine. (How much RAM do you have?) Yes,you need a really good single 12 volt rail, high capacity power supply once you get up there in disks. Lookat the report it creates when it ends. (copies of the reports will be in /boot/preclear_reports) Your report shows one attribute that looks odd. 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 285 For many disks, this attribute represents emergency retracts of the disk heads when power is lost. It seems high unless the disk just had power cut off rather than having its heads parked in an orderly shutdown in previous usage. /dev/sdb and /dev/sdg will never be the same disk. You can type: ls -l /dev/disk/by-id/* to see a listing of all your disks and disk partitions by model and serial number. The preclear script was written to not allow you to clear a disk that is assigned to the array, or mounted and in use. Have fun, Joe L.

Your disk looks fine. There are only two items ni the SMART report worth mentioning: 9 Power_On_Hours 0x0032 061 061 000 Old_age Always - 34907 199 UDMA_CRC_Error_Count 0x003e 200 197 000 Old_age Always - 34 The first is the run-time-hours. (it has been in operation for about 4 years) The UDMA CRC errors are usually noise pickup from cables. (try NOT to be anal with cable management unless you use good quality SHIELDED cables. ) Do not tie-wrap SATA cables together and definitely not with power cables. The errors are not bad, but you should be aware of their cause. Lastly, I'd much rather trust an older drive such as this rather than a brand new un-tested drive. Good luck with your test server.

It means the disk is timing out when communications to it are attempted. It could be a bad disk, or a bad disk controller, or a poor power supply, or poor quality splitter/drive cage connections. Notice there are TWO disks involved. They may share a common controller, or one might be causing the lock-up of the other sharing a disk controller. Some-times it is just the drive that is confused and a power cycle will fix it, other times it will not. get a smart report of the drives involved. smartctl -a /dev/sdi smartctl -a /dev/sdh

looks fine.

Seek_Error_Rate = 44 44 30 near_thresh 790278696138 I would only be concerned with this parameter, since the normalized value seems to be getting close to its failure threshold, and odds are the starting value was 100 or 200. The number of re-allocated sectors did not change, and that is good, but the number 343 is very high, and most people would RMA the drive based only on the number of re-allocated sectors. Since the seek error rate is iffy, and the re-allocated sector count high, I'd RMA. (the other parameters that are near their thresholds just have very high thresholds... they are not an issue)

nothing to be alarmed about. Both the "short" and "long" tests are automatically aborted if the drive is spun down.

I would not set cache_pressure to zero. I would in fact, set it closer to 100 as an experiment to see if it helps you. Obviously, we cannot control inodes cached vs. data blocks. (it would be nice, but that detailed control is not there0 Joe L.

does it show up in a process list? Remember, there are background processes performing the "find" commands. It will not completely self-terminate until it finishes the "find" it is currently performing. Type ps -ef | grep cache_dirs to see if it is still running. (the -q command indicated it killed process id 2395.) lsof seems to indicate there is a process id 32681still active.

cache_dirs has parameters to limit the number of levels of directories cached. It also has parameters to exclude specific directories. It sounds as if you need to either: A. install more RAM B. limit the directory depth cached. C. limit (include or exclude) specific user-shares to limit the directories cached. D. use the min-time and max-time parameters to set the min and max time between"find" commands in cache_dirs. E. modify cache_dirs as it suits YOUR needs. (It is just a shell script after all) F. stop using cache dirs. Apparently, your limited memory and high number if directory nodes COMBINED with other use of memory on your server cause the cache_dir "find"command to take too long and end up causing the directory entries in memory to be freed to be re-used by other processes accessing the disks. Joe L.

Then the process never finished the post-read phase.

So for some reason I logged back in to my box and I only have two out of three Screen sessions and I initiated them all via telnet so none on console. I ran the -t on the drive I don't see in my other existing sessions and it says precleared however I don't have a report. So what should I do next. Results below: Pre-Clear unRAID Disk /dev/sda ################################################################## 1.13 Device Model: ST3000DM001-9YN166 Serial Number: W1F0RSQZ Firmware Version: CC4B User Capacity: 3,000,592,982,016 bytes Disk /dev/sda: 3000.5 GB, 3000592982016 bytes 255 heads, 63 sectors/track, 364801 cylinders, total 5860533168 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 4294967295 2147483647+ 0 Empty Partition 1 does not end on cylinder boundary. ######################################################################## ========================================================================1.13 == == DISK /dev/sda IS PRECLEARED with a GPT Protective MBR == ============================================================================ Thanks! Neil I would look in /boot/preclear_reports

Easy, the third phase is reading AND verifying that all bytes read are all zeros (they were written as zeros in the second phase). The first reading phase sends all the data read to /dev/null, and no analysis is performed. It does not care about what is read, other than to allow the disk's SMART firmware to identify un-readable sectors. It can run much faster. The verification in the third phase makes it run at about half the speed.

Anyone? type preclear_disk.sh -? You'll see all the options. You can try the "-t" option to see if the pre-clear signature was written to the disk. That would indicate it did all but the post-read phase. Yes, you can skip the initial pre-read. Use the "-W" option. Joe L.

you look in /boot/preclear_reports If it completed, the reports are there.