July 9, 201015 yr So after doing some searching on SMART it looks like I should be paying attention mostly to Reallocated Sector Count and Current Sector Pending Count. I have a new 2TB drive coming from amazon next week, to replace one of these drives, and I'm assuming Drive 2 would be the best candidate to replace since it has 86 Reallocated sectors (and it is my smallest drive). How concerned should I be that my current Parity drive has 272 Current Sectors Pending? Anything else I should be watching? Attached are the SMART logs for Parity, Drive 1, and Drive 2 on my box. Thanks! Parity Drive Statistics for /dev/hda ST3750640A_5QD33919 smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3750640A Serial Number: 5QD33919 Firmware Version: 3.AAE User Capacity: 750,156,374,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Fri Jul 9 06:04:27 2010 GMT+8 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 202) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 113 094 006 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 095 093 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 57 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 19 7 Seek_Error_Rate 0x000f 070 060 030 Pre-fail Always - 10601350 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 248 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 29 187 Reported_Uncorrect 0x0032 097 097 000 Old_age Always - 3 189 High_Fly_Writes 0x003a 092 092 000 Old_age Always - 8 190 Airflow_Temperature_Cel 0x0022 073 054 045 Old_age Always - 27 (Lifetime Min/Max 27/27) 194 Temperature_Celsius 0x0022 027 046 000 Old_age Always - 27 (0 21 0 0) 195 Hardware_ECC_Recovered 0x001a 051 049 000 Old_age Always - 4639132 197 Current_Pending_Sector 0x0012 087 086 000 Old_age Always - 272 198 Offline_Uncorrectable 0x0010 087 086 000 Old_age Offline - 272 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 3 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 3 occurred at disk power-on lifetime: 145 hours (6 days + 1 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 a8 66 ce e0 Error: UNC at LBA = 0x00ce66a8 = 13526696 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 00 a7 66 ce e0 00 01:32:25.650 READ DMA EXT 25 00 00 a7 62 ce e0 00 01:32:25.610 READ DMA EXT 25 00 00 a7 5e ce e0 00 01:32:25.570 READ DMA EXT 25 00 00 a7 5a ce e0 00 01:32:29.652 READ DMA EXT 25 00 00 a7 56 ce e0 00 01:32:26.092 READ DMA EXT Error 2 occurred at disk power-on lifetime: 145 hours (6 days + 1 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 74 65 ce e0 Error: UNC at LBA = 0x00ce6574 = 13526388 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 00 a7 62 ce e0 00 01:32:25.650 READ DMA EXT 25 00 00 a7 5e ce e0 00 01:32:25.610 READ DMA EXT 25 00 00 a7 5a ce e0 00 01:32:25.570 READ DMA EXT 25 00 00 a7 56 ce e0 00 01:32:25.530 READ DMA EXT 25 00 00 a7 52 ce e0 00 01:32:26.092 READ DMA EXT Error 1 occurred at disk power-on lifetime: 145 hours (6 days + 1 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 63 c4 e0 Error: UNC at LBA = 0x00c46365 = 12870501 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 00 a7 62 c4 e0 00 01:31:49.754 READ DMA EXT 25 00 00 a7 5e c4 e0 00 01:31:49.714 READ DMA EXT 25 00 00 a7 5a c4 e0 00 01:31:49.674 READ DMA EXT 25 00 00 a7 56 c4 e0 00 01:31:49.634 READ DMA EXT 25 00 00 a7 52 c4 e0 00 01:31:49.594 READ DMA EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 243 - # 2 Short offline Aborted by host 80% 32 - # 3 Short offline Aborted by host 80% 32 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
July 9, 201015 yr Author Drive1 Statistics for /dev/hdb ST3500630A_5QG0XZHR smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3500630A Serial Number: 5QG0XZHR Firmware Version: 3.AAE User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Fri Jul 9 06:21:26 2010 GMT+8 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 163) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 118 097 006 Pre-fail Always - 196254121 3 Spin_Up_Time 0x0003 094 093 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 80 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 076 060 030 Pre-fail Always - 42210033 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 767 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 100 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 068 050 045 Old_age Always - 32 (Lifetime Min/Max 30/32) 194 Temperature_Celsius 0x0022 032 050 000 Old_age Always - 32 (0 20 0 0) 195 Hardware_ECC_Recovered 0x001a 068 058 000 Old_age Always - 117762351 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 27 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 26 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 26 occurred at disk power-on lifetime: 524 hours (21 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 00 00 00 f0 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 08 00 00 00 f0 00 00:01:52.195 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:52.180 READ DMA EXT 10 00 3f 00 00 00 b0 00 00:01:51.728 RECALIBRATE [OBS-4] 25 00 08 00 00 00 f0 00 00:01:51.286 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:50.839 READ DMA EXT Error 25 occurred at disk power-on lifetime: 524 hours (21 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 00 00 00 f0 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 08 00 00 00 f0 00 00:01:52.195 READ DMA EXT 10 00 3f 00 00 00 b0 00 00:01:52.180 RECALIBRATE [OBS-4] 25 00 08 00 00 00 f0 00 00:01:51.728 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:51.286 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:50.839 READ DMA EXT Error 24 occurred at disk power-on lifetime: 524 hours (21 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 00 00 00 f0 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 08 00 00 00 f0 00 00:01:48.683 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:48.250 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:51.728 READ DMA EXT c6 00 10 00 00 00 b0 00 00:01:51.286 SET MULTIPLE MODE 00 00 40 00 00 00 00 06 00:01:50.839 NOP [Abort queued commands] Error 23 occurred at disk power-on lifetime: 524 hours (21 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 00 00 00 f0 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 08 00 00 00 f0 00 00:01:48.683 READ DMA EXT 25 00 08 00 00 00 f0 00 00:01:48.250 READ DMA EXT c6 00 10 00 00 00 b0 00 00:01:47.787 SET MULTIPLE MODE 00 00 40 00 00 00 00 06 00:01:51.286 NOP [Abort queued commands] ef 03 40 00 00 00 b0 02 00:01:50.839 SET FEATURES [set transfer mode] Error 22 occurred at disk power-on lifetime: 524 hours (21 days + 20 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 84 51 00 00 00 00 f0 Error: ICRC, ABRT at LBA = 0x00000000 = 0 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 08 00 00 00 f0 00 00:01:48.683 READ DMA EXT c6 00 10 00 00 00 b0 00 00:01:48.250 SET MULTIPLE MODE 00 00 40 00 00 00 00 06 00:01:47.787 NOP [Abort queued commands] ef 03 40 00 00 00 b0 02 00:01:47.785 SET FEATURES [set transfer mode] 25 00 08 00 00 00 f0 00 00:01:50.839 READ DMA EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 761 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. Drive 2 Statistics for /dev/sda ST3500641AS_3PM0V967 smartctl version 5.38 [i486-slackware-linux-gnu] Copyright © 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.9 family Device Model: ST3500641AS Serial Number: 3PM0V967 Firmware Version: 3.AAJ User Capacity: 500,107,862,016 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Fri Jul 9 06:22:16 2010 GMT+8 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED See vendor-specific Attribute list for marginal Attributes. General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 430) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 255) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 117 084 006 Pre-fail Always - 152987731 3 Spin_Up_Time 0x0003 091 085 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 499 5 Reallocated_Sector_Ct 0x0033 098 098 036 Pre-fail Always - 86 7 Seek_Error_Rate 0x000f 086 060 030 Pre-fail Always - 428403382 9 Power_On_Hours 0x0032 090 090 000 Old_age Always - 9617 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 134 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 072 038 045 Old_age Always In_the_past 28 (Lifetime Min/Max 28/28) 194 Temperature_Celsius 0x0022 028 062 000 Old_age Always - 28 (0 15 0 0) 195 Hardware_ECC_Recovered 0x001a 066 046 000 Old_age Always - 105588514 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay.
July 9, 201015 yr How concerned should I be that my current Parity drive has 272 Current Sectors Pending? Anything else I should be watching? You should be VERY concerned about sectors pending reallocation on ANY drive. You should immediately perform a parity check. Those sectors pending re-allocation could not be read, that is why they are pending re-allocation. That means you can not rely on parity to re-construct ANY drive (or at least parts of what you attempt to re-construct would be trashed if they were on any of the 272 sectors that cannot be read) By performing a parity check, those sectors should be re-allocated since when their respective read fails, and unRAID forces them to be re-written. Joe L.
July 9, 201015 yr Statistics for /dev/hda ST3750640A_5QD33919 197 Current_Pending_Sector 0x0012 087 086 000 Old_age Always - 272 198 Offline_Uncorrectable 0x0010 087 086 000 Old_age Offline - 272 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 19 This drive needs to be pre-cleared and if the Current_Pending_Sectors do not go to 0 then you cannot trust it. Reallocated is of concern when it is high, but it also means, a problem was determined, handled and this is how many problem sectors which are now pointing to other sectors. Pending Sectors is how many sectors having difficulty being read. They will be reassigned on the "next write operation". This is why preclearing a drive helps, because it is a desctructive write. The sector which is known to be bad and is marked pending for reallocation will be handled in the future. offline_uncorrectable means these sectors cannot be repaired. Speaking Frankly, I would replace the parity drive. (the 750 with the 272 pending sectors). If all is good, Then I would do a few preclear passes on the 750 and see how the smartlog compares.
July 9, 201015 yr Author Okay, so since I am a newbie just wanted to check on my next steps here: #1 Run a another parity check and if the pending sectors are still there afterwards go to #2 #2 Bring the array down, preclear the drive, plug the drive back into the array and have it rebuild if it still has issues then #3 #3 get another new drive
July 9, 201015 yr Okay, so since I am a newbie just wanted to check on my next steps here: #1 Run a another parity check and if the pending sectors are still there afterwards go to #2 #2 Bring the array down, preclear the drive, plug the drive back into the array and have it rebuild if it still has issues then #3 #3 get another new drive Here is what I would do with this one. >> #1 Run a another parity check and ... Today. Now. >> I have a new 2TB drive coming from amazon next week, to replace one of these drives If this is not too far in the future, When it comes in swap this for the parity drive. You cannot use it as a data drive when the parity drive is only 750GB. The parity drive must be the largest or equal to the largest drive in the array. When you are up on good parity. Preclear the 750. and see how the smart stats look.
July 10, 201015 yr i recently pre-cleared a new samsung drive and got the final smart report Jul 8 12:45:21 Tower preclear_disk-diff[881]: ============================================================================ Jul 8 12:45:21 Tower preclear_disk-diff[881]: S.M.A.R.T. error count differences detected after pre-clear Jul 8 12:45:21 Tower preclear_disk-diff[881]: note, some 'raw' values may change, but not be an indication of a problem Jul 8 12:45:21 Tower preclear_disk-diff[881]: 55c55 Jul 8 12:45:21 Tower preclear_disk-diff[881]: < 1 Raw_Read_Error_Rate 0x002f 252 252 051 Pre-fail Always - 0 Jul 8 12:45:21 Tower preclear_disk-diff[881]: --- Jul 8 12:45:21 Tower preclear_disk-diff[881]: > 1 Raw_Read_Error_Rate 0x002f 100 100 051 Pre-fail Always - 0 Jul 8 12:45:21 Tower preclear_disk-diff[881]: 67c67 Jul 8 12:45:21 Tower preclear_disk-diff[881]: < 195 Hardware_ECC_Recovered 0x003a 252 252 000 Old_age Always Jul 8 12:45:21 Tower preclear_disk-diff[881]: --- Jul 8 12:45:21 Tower preclear_disk-diff[881]: > 195 Hardware_ECC_Recovered 0x003a 100 100 000 Old_age Always Jul 8 12:45:21 Tower preclear_disk-diff[881]: 72c72 Jul 8 12:45:21 Tower preclear_disk-diff[881]: < 200 Multi_Zone_Error_Rate 0x002a 252 252 000 Old_age Always - 0 Jul 8 12:45:21 Tower preclear_disk-diff[881]: --- Jul 8 12:45:21 Tower preclear_disk-diff[881]: > 200 Multi_Zone_Error_Rate 0x002a 100 100 000 Old_age Always - 1 can someone tell me what these numbers mean and if it indicate any problems for the hdd? thanks
July 10, 201015 yr The only parameters that have "raw" values that have meaning to anyone other than the manufacturer are the temperature, the re-allocated sectors, and the sectors pending re-allocation. The other parameters have "normalized values that must stay above their respective "threshold" values for the drive to be considered good. 252 is a value assigned by some manufacturers for some attributes to indicate an initial state. Once their drive has a few (minutes/hours?) on it, the new stating value of "100" is frequently assigned. None of the attributes that changed are failing or near their failure threshold either before, or after the preclear (you are looking at the differences in the two SMART reports). See this page to learn more: http://en.wikipedia.org/wiki/S.M.A.R.T. Joe L.
July 10, 201015 yr Author Well I ran another parity check and There are still 272 sectors pending. So for some reason those sectors weren't re-allocated. My new drive comes in on Wed, so I guess I will have to sit tight until then.
July 10, 201015 yr Well I ran another parity check and There are still 272 sectors pending. So for some reason those sectors weren't re-allocated. My new drive comes in on Wed, so I guess I will have to sit tight until then. They will NOT be re-allocated until those sectors are written to. The only way I know to force it to write is to set a new initial configuration, or, easier yet... Stop the array Un-assign the parity drive Start the array with it un-assigned Stop the array once more Re-assign the parity drive Start the array (It will think the parity drive is a new one and write to it.) Basically, that series of steps will force a complete re-write of the parity drive, and hopefully, a re-allocation of the bad sectors. Regardless, 272 is a huge number, and you should consider an RMA in the near future for that drive, especially if more sectors end up pending re-allocation in the coming weeks/months. Joe L.
July 11, 201015 yr Author Did the stop, unassign, start, stop, reassign, start, rebuild. No dice, still have 272 pending after the latest SMART scan. Will just replace it as soon as the new drive is delivered. Once that's done will try some pre-clearing when it's no longer in service.
August 23, 201015 yr Hi Joe, don't mean to hijack this thread but I'm still trying to get my head around some of the SMART stuff for preventative maintenance myself. In an early quote in this thread, you said:- "By performing a parity check, those sectors should be re-allocated since when their respective read fails, and unRAID forces them to be re-written." but near the end you said:- "They will NOT be re-allocated until those sectors are written to. The only way I know to force it to write is to set a new initial configuration, or, easier yet..." can you explain this apparent discrepency? it would be a great help, thanks! m
August 28, 201015 yr Hi Joe, don't mean to hijack this thread but I'm still trying to get my head around some of the SMART stuff for preventative maintenance myself. In an early quote in this thread, you said:- "By performing a parity check, those sectors should be re-allocated since when their respective read fails, and unRAID forces them to be re-written." but near the end you said:- "They will NOT be re-allocated until those sectors are written to. The only way I know to force it to write is to set a new initial configuration, or, easier yet..." can you explain this apparent discrepency? it would be a great help, thanks! m It is not a discrepancy. One is after a disk is assigned to the array, the other if not yet assigned to the array. After the disks are assigned to the array and are part of the array If a "read" fails, then unRAID will read all the corresponding sectors of the other array disks in addition to the parity disk and reconstruct the data it could not read. It also then writes that sector the the disk it could not read. this action of writing to an un-readable sector allows the firmware on the disk to re-try to write the original sector, and then attempt to read it. If successful, no re-allocation is needed and the original sector will still be used. It will assume the "write" was poorly done, and that once re-written it is fine. If the attempt to re-write the original sector fails, a new sector is allocation from the pool of spare sectors. Before the disks are assigned to the array, if a bad sector is detected in the pre-read phase of the pre-clear, then the "writing" of zeros during the clearing should re-allocate the sector (again if an attempt to write the original sector fails) No additional unreadable sectors should be detected during the clearing post-read phase. If you end up with sectors pending re-allocation after the post-read phase, the disk is having difficulty in writing to its sectors... Additional clearing cycles are warranted to learn if it is a disk controller issue, a disk drive issue, a cabling issue, or a power supply issue.. Joe L.
August 29, 201015 yr Well I ran another parity check and There are still 272 sectors pending. So I'm still confused by this. Since slowrolling's parity drive is clearly 'assigned' in the array, how come manually performing the parity check didn't then cause read errors for those 272 sectors and why then did unRAID not then force them to be re-written as you describe - or does this rewrite specifically not apply to the parity disk?
August 29, 201015 yr Well I ran another parity check and There are still 272 sectors pending. So I'm still confused by this. Since slowrolling's parity drive is clearly 'assigned' in the array, how come manually performing the parity check didn't then cause read errors for those 272 sectors and why then did unRAID not then force them to be re-written as you describe - or does this rewrite specifically not apply to the parity disk? Apparently, the logic used to re-write a sector that failed when read is not in the parity checking routine. I can't explain it otherwise. Perhaps we can ask lime-technology.... Is this an area where unRAID can be improved? To re-write a parity disk sector which is un-readable, after re-computing the correct parity, to attempt to allow SMART to re-allocate the sector on the parity disk. Joe L.
August 29, 201015 yr I guess there could be something chronically wrong with the disk in that it genuinely can't reallocate those sectors (if in fact unRAID HAS asked them to be re-written). It would be very useful to get limetech's feedback on this one!! Meanwhile thanks for the feedback Joe. I will certainly be using the preclear script on all my new unRAID (and possible non-unRAID!) drives when commissioning them in future!
August 29, 201015 yr Apparently, the logic used to re-write a sector that failed when read is not in the parity checking routine. Absolutely not the case. Any time a disk read fails, and unRAID is able to reconstruct the data, it will also write the reconstructed data to the failed disk. If the write fails, then the disk is disabled. Here's the thing about SMART - it's really not all that reliable. There's a paper out there (I think the one from google, but can't find it at the moment) that mentions a high number of drives that failed never reported any SMART problems at all. Also, you are assuming the drive firmware is doing the right thing and there are no bugs in it's SMART handling - huge assumptions IMHO.
August 29, 201015 yr Apparently, the logic used to re-write a sector that failed when read is not in the parity checking routine. Absolutely not the case. Any time a disk read fails, and unRAID is able to reconstruct the data, it will also write the reconstructed data to the failed disk. If the write fails, then the disk is disabled. Here's the thing about SMART - it's really not all that reliable. There's a paper out there (I think the one from google, but can't find it at the moment) that mentions a high number of drives that failed never reported any SMART problems at all. Also, you are assuming the drive firmware is doing the right thing and there are no bugs in it's SMART handling - huge assumptions IMHO. Tom, We are not questioning the logic when a read of a data disk fails. We are questioning the logic when a user simply presses the "Check" button and it is the "parity" disk that reports the read error. In the users situation, there are 272 sectors pending re-allocation on their parity disk. A subsequent "check" does not re-allocate them. If, as you suggest, the "read" of the parity disk fails once more when parity is being checked, will the parity check process re-write the correct parity to the parity drive? I know it will if parity is read (with no failure) and parity calculated, and a mis-match with the data detected... but will it if a read-failure of the parity disk occurs? Not to say there can't be disk firmware issues, but seems that this might involve very different logic in the unRAID "md" driver.
August 29, 201015 yr Apparently, the logic used to re-write a sector that failed when read is not in the parity checking routine. Absolutely not the case. Any time a disk read fails, and unRAID is able to reconstruct the data, it will also write the reconstructed data to the failed disk. If the write fails, then the disk is disabled. Here's the thing about SMART - it's really not all that reliable. There's a paper out there (I think the one from google, but can't find it at the moment) that mentions a high number of drives that failed never reported any SMART problems at all. Also, you are assuming the drive firmware is doing the right thing and there are no bugs in it's SMART handling - huge assumptions IMHO. Tom, We are not questioning the logic when a read of a data disk fails. We are questioning the logic when a user simply presses the "Check" button and it is the "parity" disk that reports the read error. In the users situation, there are 272 sectors pending re-allocation on their parity disk. A subsequent "check" does not re-allocate them. If, as you suggest, the "read" of the parity disk fails once more when parity is being checked, will the parity check process re-write the correct parity to the parity drive? I know it will if parity is read (with no failure) and parity calculated, and a mis-match with the data detected... but will it if a read-failure of the parity disk occurs? Not to say there can't be disk firmware issues, but seems that this might involve very different logic in the unRAID "md" driver. The driver operates on disks in terms of "columns", that is, each disk is a column, and it so happens that column 0 is parity, but during a parity check the driver has no knowledge really of this. It just issues reads for each enabled disk in the column, waits for them all to finish, and then xor's all the data together to see if the result is 0. If a read fails, then there's a different code path where it instead xors all the data together except for the failing column; it then writes this resultant data to the failing column disk. So whether the column that failed is parity or a data disk, makes no difference. The applicable code is on lines 1171-1230 in unraid.c. My point about SMART is that in my experience its interpretation and implementation tends to be a bit "sloppy" in hard drive firmware. I haven't looked for a while, but you can never actually find any SMART implementation details on any of the drive manufacturers websites. In the case of the "Current Pending Sector Count" I think it's probably not doing what the spec on wikipedia says it's doing. The OP said, Did the stop, unassign, start, stop, reassign, start, rebuild. No dice, still have 272 pending after the latest SMART scan. This implies to me perhaps one of two things: 1) the drive f/w is buggy. 2) the value 272 is some kind of "baseline", maybe from manufacturing test. Or perhaps the sectors are from some region not accessible. I would bet my money on option 1. Also, that "Current Pending Sector Count" implies a specific implementation - that is, that the drive maintains spares at the end of the cylinder. I've seen drives that don't do that. Instead they have spare cylinders at the end of zones and fail out the entire cylinder. This is actually a big problem with some of the SMART attributes: many of them imply a certain implementation & if the drive f/w does not implement that method exactly, then the programmer makes a "guess" about what should be in that field. Probably what I would do in the OP case is just watch the SMART values and look for deltas over time. So if now "Current Pending Sector Count" is 272, and 3 months later it's still 272, well probably the drive is just fine. If the counter keeps increasing, then maybe request an RMA from the vendor, explaining why the drive is being RMA'ed and perhaps you'll get an explanation from them if the drive is suspect or not.
August 30, 201015 yr Thanks for the further explanation(s) Tom. The term SMART sounds more and more ironic...
Archived
This topic is now archived and is closed to further replies.