Joe L.

I did. kill -9 did not kill it. If a process is in a system call waiting on a kernel level interrupt, no signal can kill it. (not even kill -9) Typically, this is due to some kind of driver bug and a deadlock situation in the kernel. All you can do at that point is what to did... reboot.

unformatted indicates not mounted. It could be as a result of a poor shutdown and the transactions on the drives were being replayed. That can take as long as 30 minutes or more. If you had waited, the drive might have mounted itself and then shown as expected. Unless you know WHY the drive was not mounted, you have no reason to RMA the drive. If it happens again, capture the syslog for analysis.

You stop the array,assign the drive to an unRAID slot, then when you start the array it will present it as unformatted and show a "Format"button. Pressing it will format the drive and allow it to be used in the array. If not pre-cleared, and added to an array with established parity protection, the drive would first be cleared by unRAID. this clearing step takes many hours during which your array is off-line. It is one of the main reasons the drive preclear script was developed, to eliminate the lengthy down-time. (lime-tech used to sell pre-cleared drives, but found it impossible to compete with newegg, etc. ) When the pre-clear script is complete, a special signature is written to the drive to allow it to be recognized as pre-cleared.

Your disks all look fine.

Well, you used the "-n"option. -n = Do NOT perform preread and postread of entire disk that would allow SMART firmware to identify bad blocks. Therefore, it only wrote to the disk. You asked it to not bother to locate any unREADABLE sectors. It therefore could not re-allocate any that were un-readable. (since it does not yet know they are un-readable... it has never tried to read them) Normally, the disk is fully read first, to allow it to determine if any sectors are un-readable. Normally it is subsequently re-read AFTER zeroing to ensure the zeros were properly written. You elected to skip both those steps when you used the "-n" option. the portions of the process you elected to skip are why the disk finished so quickly. Good luck. The drive may be added to an existing array without it clearing the drive, but you might want to monitor it more closely as you load it with data. At the least, perform a full manual parity check once installed. (that will read it in its entirety)

For disks that will have a GPT partition defined by unRAID a "protective" MBR partition is put into place to fool other older utilities into thinking the entire disk is allocated even if they have not been upgraded to handle GPT partitions. (most older programs have not) I suppose that the next time I update the preclear script I can describe that "protective" partition better. The protective partition starts on sector 1 and goes for the entire drive possible, using the bits available in the MBR structure. Since there are only 16 bits, the biggest disk partition the old style MBR can define is 2.2TB. The protective partition is therefore defined as 2.2TB. That protective MBR is not actually used on GPT formatted drives... Think of it as a placeholder to make older utilities and programs happy. The actual GPT partition is always 4k-aligned and defined in an area further past the first 512 bytes in the disk where the MBR is located. It utilizes the entire 3TB drive. Joe L.

looks great. No sectors marked for re-allocation, and none re-allocated. Nothing else failing or near failing. Joe L.

The first preclear showed that: 1. The drive had failed SMART at some point in the past on an over-temperature threshold. (It was currently within temp limits) The drive started with 3 sectors that had been re-allocated, and with 517 that were pending re-allocation. The pre-clear then read the entire drive... allowing the drive to detect any additional sectors it could not read. It did not find any, so there were 517 sectors that were pending re-allocation. The pre-clear then write zeros to the entire drive. The disk FIRST tried re-writing the original location on the disk platter rather than re-allocation. That apparently worked for 509 sectors. (or rather, after the post-read, there were only 8 sectors pending re-allocation, so apparently 509 were re-written in place rather than re-allocated since no additional sectors had been re-allocated) Every subsequent pass seems to detect a small number of un-readable sectors, and apparently they always seem to be able to be re-written in place. No additional re-allocated sectors are occurring. I would not trust the drive. (unless you are using it on a marginal power supply, in which case, it might just be reacting to the voltages it is being fed, but regardless... unless something changes, odds are you cannot trust it.) Good luck with RMA'ing it. Some-times manufacturers like to reject a claim when the drive has been subjected to an over-temperature environment.

also, you can use hdparm -A /dev/sdg and fdisk -l /dev/sdg to learn more about the specific device. (odds are VERY HIGH) /dev/sdg is not the disk you think it is)

It is not anything to worry about, and not a mis-interpertation either. The normalized value for those two parameters is 100. The failure threshold is 97 and 99 respectively. Only the manufacturer knows how many errors would cause the value to decrement from 100 to 97 (or 100 to 99) It might be 1 to 1. It could just as easily be 100 to 1 or 10000 to 1. (there is no real standard for setting the starting value or thresholds...) The raw counts are both zero, so you''ve apparently never had to re-try spinning up. (or had an end-to-end error, whatever that is) Joe L.

You do not need to do anything more. The disk looks great. In the absence of a "-a" or "-A" option, the value you've elected in your unRAID preferences is used. (apparently, you have your set to 4k-aligned.) The partition starting on sector 64 is perfect;y fine in any array and with any disk. There is only one model of disk from one manufacturer (EARS drives) that performed poorly when partitioned to start on sector 63 and even that only shows the lesser performance when dealing with small files. When reading music or movie media files, most people will never notice the difference, even with an EARS drive partitioned on sector63, since the performance is still more than enough listen/view with no issues. Joe L.

unfortunately, the SMART reports do NOT tell if the preclear was successful, or if there were issues reading back the zeros that were written to the drive. The smart reports can only tell you if there are sectors re-allocated/pending reallocation. (or other smart attributes failing or near failing) For that information, you really need the preclear "rpt" file.

no, it is not. The results can be found in the /boot/preclear_reports directory. There are three files for each disk (the last set is saved on any given day). The "start" SMART report, the "finish" SMART report, and the actual "rpt" analysis. Joe L.

Can't tell. you did not post a SMART report. All we see is a snip of your syslog, and those errors could be power supply, disk controller, loose cabling, or disk related.

You should be fine. The number of re-allocated sectors did not change. If you are unsure, preclear it once more. If the number of re-allocated sectors changes, then you might see them from time to time, and the disk is not a great candidate. But... if it stays the same, use the disk. I've got one disk that has 100 re-allocated sectors, and that number has never changed. I trust it. Most disks have several thousand spare sectors to be used for re-allocation. The 36 is not an issue. Joe L.

Well... the original 4 sectors were apparently re-written in place, and not re-allocated, but then on the second cycle one additional sector was not readable initially, but re-written in place on the zeroing phase. I'd run it through another few cycles. If it still has an occasional sector show as un-readable, I'd not trust it for anything critical. If it is all OK, then go ahead and use it if you like... (Or RMA it, if in warranty) Of course, you can always put it in a windows OS, and blame any future data corruption on Microsoft.

Thanks for the reply Joe. Is that normal to run out of memory for 3 preclears running at the same time? I have 8GB RAM in the server and only did it because the FAQ mentioned 4 or more preclears shouldn't be run at the same time. After the second crash, I formatted the usb drive and reloaded again from scratch. I just started the preclear on one drive only. As of 7am this morning it seems to be still going so hopefully it'll go ok all the way till the end and I can start the 2nd one tonight. I've got absolutely no idea. It would depend on lots of factors. I would not have thought you would have issues... but I was not the one who wrote that part of the wiki. If your syslog filled with errors, that could use up all your memory. If you were performing a parity check/sync, all available memory would be used as cache. (unless you have more RAM than disk space) I would run a tail -f /var/log/syslog and see if anything is filling it. I would also perform a memory test, if you have not done one... who knows, you might have less RAM than you think.

basically, you crashed. (probably ran out of free memory) The dump seems to indicate the kernel was attempting to find the lru (least recently used) page of memory so it could re-use it. Joe L.

a very nice summary. Nobody knows if a drive with 0 re-allocated sectors is actually defect free, or just set to zero by the manufacturer after mapping an initial set of defects. I can not know for sure, but the facts I know are that it takes a finite amount of time to read all the sectors of a disk. I know we can read at roughly 100MB/s. I have no idea what the speed of an internal only test might be. Whatever it is, it must be very similar to a "long" test as issued by the smartctl utility. I'm not sure that each disk is actually tested to see that every bit is readable. With that in mind, does each drive sit on the manufacturing line for the 4 to 6 hours needed for a full test? Nobody knows except the manufacturer. I doubt the drives are tested for that length of time... it would limit the number of drives you could manufacture, as the tests would take FAR longer than the actual assembly time. Joe L.

It will report the partition as 2.2TB to older utilities. I've never seen the message you described, but them I've never seen a 3TB drive Probably just how "fdisk" is describing it. (and fdisk is an older utility) Don't worry though, the preclear script does not use "fdisk" to actually create a partition. Joe L.

Since it just finished a post-read, that should do. I noticed it originally had 5 sectors pending re-allocation, and they were all re-allocated when writing zeros, but then in the post-read, 13 more were identified as un-readable.... We'll see what happens this time.

IT is very unusual for a pre-cleared disk to have sectors pending re-allocation. You have 13 sectors pending re-allocation. They would have had to have been identified during the post-read phase. That, combine with the two failed "short tests" indicates you need to go through another pre-clear cycle before trusting the disk in your array. next time, you should post the pre-clear report, not just a smartctl report, as it will show more of how the disk changed during the process.

it is there, as an attachment to the first post. (I just looked to verify) Scroll all the way to the bottom of it to see it.

Your disks look good. Enjoy.

All the sectors that had been marked as un-readable were able to be written to their original sectors and not re-allocated. That would indicate a problem when they were originally written. (in its prior life)