Joe L.

no worry.

No... and you should read the first post in this thread to learn how to interpert the results of a smart report. The issue is this. The pre-clear script ONLY shows the differences between the beginning SMART report and the post clear SMART report. If the beginning one was failing and the end one is failing too, then no output pertaining to it would print. The lines you showed are just factory initialized values (253) being set to a median starting value (100) once the drive starts getting some use. Load cycle incrementing is a good thing. If it did not increment at least once, your disk heads would not have loaded onto the platters and your disk would be non-functional.

I'd also be interested in seeing what fdisk -l /dev/sda and blockdev --getsz /dev/sda and sfdisk -g /dev/sda show for the disk. Joe L.

One more thing to try. It will not fix it, but it will let us see what did happen. The two values printed should be the MS-DOS expected signature at bytes 510 and 511 of the MBR. They should not be zero as you are seeing in the output. Please post the output of dd if=/dev/sda bs=512 count=2 | od -x -A d It should look a lot like this (the actual numbers in the lines will vary based on the size of the disk, but the "aa55" should be there on that line starting with address 0000496): root@Tower:/boot# dd if=/dev/sda bs=512 count=2 | od -x -A d 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0000448 0000 0000 0000 003f 0000 6341 1d38 0000 0000464 0000 0000 0000 0000 0000 0000 0000 0000 * 0000496 0000 0000 0000 0000 0000 0000 0000 aa55 0000512 0000 0000 0000 0000 0000 0000 0000 0000 * 0001024 2+0 records in 2+0 records out 1024 bytes (1.0 kB) copied, 0.0174509 s, 58.7 kB/s Edited to ask for a count=2 instead of count=1 Joe L.

Can't really tell. First I'd try a power cycle. Then you can zero the "MBR" and the sector following it by typing dd if=/dev/zero of=/dev/sda bs=512 count=2 (Just in case the data that was in the second sector is confusing the fdisk program since you added the jumper) Next, try a preclear again. See if it responds at all. Joe L.

Yes you should be concerned. We have no idea what that parameter is, but if it is failing you do not want that drive in your server. RMA it. That is not an issue, most newer drives are not in its database. Those are the speeds reported by the last of the "dd" commands. That speed is affected by anything else going on at the same time on the server. Joe L.

Figured I'd post one of my own preclear results... This is a 1.5TB Seagate ST31500341AS. = unRAID server Pre-Clear disk /dev/sda = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Disk Temperature: 30C, Elapsed Time: 22:56:52 -Average speed was 84 MB/s. ============================================================================ == == Disk /dev/sda has been successfully precleared == ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 54c54 < 1 Raw_Read_Error_Rate 0x000f 100 100 006 Pre-fail Always - 6694 --- > 1 Raw_Read_Error_Rate 0x000f 118 100 006 Pre-fail Always - 195233335 <-- normalized value improved during preclear 58c58 < 7 Seek_Error_Rate 0x000f 100 253 030 Pre-fail Always - 471 --- > 7 Seek_Error_Rate 0x000f 100 253 030 Pre-fail Always - 91031 <- just raw value changes... ignore these 63,66c63,66 < 188 Unknown_Attribute 0x0032 100 253 000 Old_age Always - 0 < 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 < 190 Airflow_Temperature_Cel 0x0022 073 070 045 Old_age Always - 27 (Lifetime Min/Max 25/27) < 195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always --- > 188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0 > 189 High_Fly_Writes 0x003a 086 086 000 Old_age Always - 14 <- there were some high-fly-writes detected, but normalized value nowhere near threshold. > 190 Airflow_Temperature_Cel 0x0022 070 064 045 Old_age Always - 30 (Lifetime Min/Max 25/36) <-- temp got up to 36 during writes, ended at 30C. > 195 Hardware_ECC_Recovered 0x001a 059 048 000 Old_age Always 69,72c69,72 < 199 UDMA_CRC_Error_Count 0x003e 200 253 000 Old_age Always - 0 < 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 151629525417984 < 241 Unknown_Attribute 0x0000 100 253 000 Old_age Offline - 0 < 242 Unknown_Attribute 0x0000 100 253 000 Old_age Offline - 5746 --- > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 <- factory 253 value changes to starting 200 value. > 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 231743550390295 <-- yes, head was flying... no idea of how to interpret raw value... sure is not seconds, or even microseconds. > 241 Unknown_Attribute 0x0000 100 253 000 Old_age Offline - 2931361246 > 242 Unknown_Attribute 0x0000 100 253 000 Old_age Offline - 455163613 ============================================================================ root@Tower2:/boot# Since I have no need to add this immediately to the array, I'll do one or two more preclear cycles on it while it is un-assigned. Joe L.

No worry. The "normalized" current value is 100, and did not change, and is still the initial value given by the manufacturer, and is nowhere near the failure threshold of 51. All drives have internal raw read errors, some report them, some do not, and only the manufacturer knows how to interpret the "raw" values. Enjoy your new drives.

Offline data collection activity is another name for self tests done by the drive when it thinks it is idle. Apparently it tried to run one but it was interrupted by the pre-clearing accesses. Your drive looks fine.

It writes its output to the syslog. In addition the smart reports for the drives are all in the /tmp directory. Both are available until you reboot. Joe L.

Drive /dev/sdg Prior to the pre-clear there was 1 re-allocated sector. < 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 1 --- After the pre-clear, there were 4 re-allocated sectors. > 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 4 Prior to the pre-clear there was 1 re-allocated "event" (the one sector it had re-allocated) < 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 1 Prior to the pre-clear there were 3 sectors pending re-allocation when next written. < 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 3 --- After the pre-clear there were 4 re-allocated events (the 4 sectors it re-allocated) > 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 4 After the pre-clear there are no more sectors pending re-allocation. > 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0 Notice in all cases the normalized value of 100 is un-changed and nowhere near the "normalized" failure threshold of 5 Since most large disks have several thousand spare sectors, this is expected. There is nothing really wrong with the drive and they would have every right to consider it to not be failing. An RMA is not in order unless you see the re-allocated sector count growing over the next months/years. I would run a few more pre-clear cycles on the drive. It the re-allocated sector count continues to increment, then you have the ammunition to RMA the drive and defend it is defective. If the re-allocation sector cont goes un-changed, you'll probably be fine for a very long time. Joe L.

Sorry you have a bad drive, but better learning now than after you added it to your array.

Since you've already move the drive from one disk controller to another, it would eliminate the disk controller from being a possibility. The drive initially responds when the SMART report is first performed and then it times-out. The OS resets it and tries again, it still fails to respond. All the subsequent writes to it fail with errors written to the syslog. Eventually, the syslog would grow to where it uses all memory, and your server would become un-responsive as you've discovered. Only other possibility, besides the drive itself, would be a poor or intermittent power connection to the drive. (try an alternate power connection) Other than that... I'd say RMA the drive. Be thankful it was discovered before you tried using it in your array. Oct 1 00:52:28 Tower kernel: ata9.00: exception Emask 0x0 SAct 0x3f80000 SErr 0x80000 action 0x6 frozen Oct 1 00:52:28 Tower kernel: ata9: SError: { 10B8B } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:98:20:9d:24/04:00:de:00:00/40 tag 19 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:a0:20:a1:24/04:00:de:00:00/40 tag 20 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:a8:20:a5:24/04:00:de:00:00/40 tag 21 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:b0:20:a9:24/04:00:de:00:00/40 tag 22 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:b8:20:ad:24/04:00:de:00:00/40 tag 23 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:c0:20:b1:24/04:00:de:00:00/40 tag 24 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9.00: failed command: WRITE FPDMA QUEUED Oct 1 00:52:28 Tower kernel: ata9.00: cmd 61/00:c8:20:b5:24/04:00:de:00:00/40 tag 25 ncq 524288 out Oct 1 00:52:28 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Oct 1 00:52:28 Tower kernel: ata9.00: status: { DRDY } Oct 1 00:52:28 Tower kernel: ata9: hard resetting link Oct 1 00:52:36 Tower kernel: ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Oct 1 00:52:36 Tower kernel: ata9.00: configured for UDMA/133 Oct 1 00:52:36 Tower kernel: ata9.00: device reported invalid CHS sector 0 Oct 1 00:52:36 Tower last message repeated 6 times Oct 1 00:52:36 Tower kernel: ata9: EH complete Oct 1 01:00:12 Tower kernel: sd 4:0:0:0: [sdj] Unhandled error code Oct 1 01:00:12 Tower kernel: sd 4:0:0:0: [sdj] Result: hostbyte=0x00 driverbyte=0x06 Oct 1 01:00:12 Tower kernel: sd 4:0:0:0: [sdj] CDB: cdb[0]=0x2a: 2a 00 de ab 6d 20 00 04 00 00 Oct 1 01:00:12 Tower kernel: end_request: I/O error, dev sdj, sector 3735776544 Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972068 Oct 1 01:00:12 Tower kernel: lost page write due to I/O error on sdj Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972069 Oct 1 01:00:12 Tower kernel: lost page write due to I/O error on sdj Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972070 Oct 1 01:00:12 Tower kernel: lost page write due to I/O error on sdj Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972071 Oct 1 01:00:12 Tower kernel: lost page write due to I/O error on sdj Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972072 Oct 1 01:00:12 Tower kernel: lost page write due to I/O error on sdj Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972073 Oct 1 01:00:12 Tower kernel: lost page write due to I/O error on sdj Oct 1 01:00:12 Tower kernel: Buffer I/O error on device sdj, logical block 466972074

It says it is running up at the top of the report: Self-test execution status: ( 249) Self-test routine in progress... 90% of test remaining.

Returned "" (blank) instead of 00000 is more interesting. Glad you took the time to give me feedback. That would probably indicate the drive did not respond at all. Interesting... It could then be a cabling issue, and not a random errant bit, or a drive that occasionally likes to not respond. (it needs to respond to get its temperature or spin-up/down status) Joe L.

Unlikely to be a cabling issue, but I can't predict what an intermittent connection would do. It continues to the end. Yes, in the /tmp directory you'll find a file named: /tmp/postread_errors$disk_basename where disk_basename is your disk under test. Check it out for the specific blocks and offsets. Th test for non-zeros bytes is fairly crude, it is just a sum of all the values returned when it reads a block of data. (block size is set to the size, in bytes, of a cylinder as reported by fdisk -l /dev/sdX If the sum of the bytes is zero, then all the bytes read in that set of blocks were zero. I do not know which specific byte/sector was non-zero. Yes, these disks that occasionally random values show up as parity errors when parity is checked, but unless you are doing a NOCORRECT check, they also then modify parity to reflect the bad data reported from the drives. They cause hair-loss, because you'll pull your hair out trying to figure out the cause of the random parity errors. (you'll have no idea which disk is the cause, because they do not report these as errors, they think they are reading the platter correctly) If not an obviously loose cable, RMA the drive. Joe L.

The same sectors repeating, to me would indicate a physical issue with the sector, not a noise sensitive issue as I first suspected. Those sectors apparently should be re-allocated, but the drive keeps re-using them since it was able to read them when the write phase occurs. They are bad, but not bad enough.... argh......

I don't think the SATA cable could cause the types of errors you are seeing. You would be getting CRC errors, not media errors. Even though it is the same cable as a different drive, it could be that specific drive is more sensitive to noise on the supply voltage. If you transpose two drives, and the problem follows the drive, then it is highly likely you do not want that drive in your array.

Do you mean try a different sata power connector on my current power supply or an entirely new power supply? You can do either as a test. Some drives perform poorly if attached to a marginal power supply, or if the voltage on the cable is "noisy" I was just trying to let you know it might not be the drive, but what it is attached to. If you are using splitters, try not to. If the power supply is marginal for your use, they perhaps a better one (with a single 12 Volt rail with high current capacity) will help.

I don't like the increasing number of sectors pending re-allocation yet no sectors are re-allocated, indicating the second attempt at writing them to their original sector worked, but then the post-read found more un-readable sectors. I'd first try a different power connection in case it is a noisy power supply, but other than that, I'd consider it a candidate for an RMA if the errors continue. In know it is not the news you wanted to hear, but it is far easier now than after it holds your data and has those same errors. Joe L.

Looks good. No re-allocated sectors, or sectors pending re-allocation. No parameters FAILING_NOW, nor any where the current value is nearing the failure-threshold. (You can see several changing from the factory 253 value to the starting value of 200.) You must have very good air flow past that drive, since its temperature only rose from 26C to 28C during the clearing cycle that lasted over 27 hours. Nice.

None of the "normalized values are below their failure thresholds, there are no re-allocated sectors or pending re-allocation. The temperature of 44C of the first drive is a bit high for my comfort. It probably needs more air flow around it. I have four of that same Hitachi drive in one of my servers and they all sit between 27C and 32C.

It does look good. Joe L.

Probably because you are not in the directory where you downloaded and un-zipped preclear_disk.sh If you log in you'll probably need to change directory first: cd /boot (assuming you put it in the top directory of the flash drive)

Only the "start" smart report is in the syslog segment you posted. Not the "post" smart report. To see if the drive is really cleared, type: preclear_disk.sh -t /dev/sdX