March 5, 201016 yr I'm currently copying 2tb of data from an ntfs drive which is mounted on my unRAID server. The data is being copied to a user share and at first it was moving at a nice pace (750gb in about 5 hours) all of which went onto Disk3 in my array. Then things slowed WAY down when it started saving to disk4 (72gb so far in approx 2.5 hours). I noticed some entries in the syslog (below) which appear directly related but I don't really understand what it means. Disk3 is a ST31500341AS Disk4 is a WD10EACS Both are attached to the same adaptec 1430sa controller. Can anyone tell me what happened and why it's so slow now? Mar 5 12:14:21 Ruprecht kernel: ata4.00: exception Emask 0x0 SAct 0x1f SErr 0x0 action 0x6 Mar 5 12:14:21 Ruprecht kernel: ata4.00: edma_err_cause=02000084 pp_flags=00000003, dev error, EDMA self-disable Mar 5 12:14:21 Ruprecht kernel: ata4.00: failed command: READ FPDMA QUEUED Mar 5 12:14:21 Ruprecht kernel: ata4.00: cmd 60/80:00:38:f5:84/00:00:7c:00:00/40 tag 0 ncq 65536 in Mar 5 12:14:21 Ruprecht kernel: res 41/04:00:38:f5:84/4f:00:7c:00:00/40 Emask 0x401 (device error) Mar 5 12:14:21 Ruprecht kernel: ata4.00: status: { DRDY ERR } Mar 5 12:14:21 Ruprecht kernel: ata4.00: error: { ABRT } Mar 5 12:14:21 Ruprecht kernel: ata4.00: failed command: READ FPDMA QUEUED Mar 5 12:14:21 Ruprecht kernel: ata4.00: cmd 60/80:08:b8:f5:84/00:00:7c:00:00/40 tag 1 ncq 65536 in Mar 5 12:14:21 Ruprecht kernel: res 41/04:24:b9:f6:84/04:00:7c:00:00/40 Emask 0x1 (device error) Mar 5 12:14:21 Ruprecht kernel: ata4.00: status: { DRDY ERR } Mar 5 12:14:21 Ruprecht kernel: ata4.00: error: { ABRT } Mar 5 12:14:21 Ruprecht kernel: ata4.00: failed command: READ FPDMA QUEUED Mar 5 12:14:21 Ruprecht kernel: ata4.00: cmd 60/80:10:38:f6:84/00:00:7c:00:00/40 tag 2 ncq 65536 in Mar 5 12:14:21 Ruprecht kernel: res 41/04:24:b9:f6:84/04:00:7c:00:00/40 Emask 0x1 (device error) Mar 5 12:14:21 Ruprecht kernel: ata4.00: status: { DRDY ERR } Mar 5 12:14:21 Ruprecht kernel: ata4.00: error: { ABRT } Mar 5 12:14:21 Ruprecht kernel: ata4.00: failed command: READ FPDMA QUEUED Mar 5 12:14:21 Ruprecht kernel: ata4.00: cmd 60/01:18:b8:f6:84/00:00:7c:00:00/40 tag 3 ncq 512 in Mar 5 12:14:21 Ruprecht kernel: res 41/04:24:b9:f6:84/04:00:7c:00:00/40 Emask 0x1 (device error) Mar 5 12:14:21 Ruprecht kernel: ata4.00: status: { DRDY ERR } Mar 5 12:14:21 Ruprecht kernel: ata4.00: error: { ABRT } Mar 5 12:14:21 Ruprecht kernel: ata4.00: failed command: READ FPDMA QUEUED Mar 5 12:14:21 Ruprecht kernel: ata4.00: cmd 60/7f:20:b9:f6:84/00:00:7c:00:00/40 tag 4 ncq 65024 in Mar 5 12:14:21 Ruprecht kernel: res 41/04:24:b9:f6:84/04:00:7c:00:00/40 Emask 0x1 (device error) Mar 5 12:14:21 Ruprecht kernel: ata4.00: status: { DRDY ERR } Mar 5 12:14:21 Ruprecht kernel: ata4.00: error: { ABRT } Mar 5 12:14:21 Ruprecht kernel: ata4: hard resetting link Mar 5 12:14:21 Ruprecht kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 5 12:14:21 Ruprecht kernel: ata4.00: configured for UDMA/133 Mar 5 12:14:21 Ruprecht kernel: ata4: EH complete
March 5, 201016 yr Looks like there may be some bad cables on that disk. (sata or power) Change the cables! (and maype try plugging it to a different SATA slot) Then check what SMART will report for that disk. Do you have a good power supply? Also, how are you doing the copying? Is it a Linux copy within the server? Or are the files travelling over the network to a windows machine, and then travelling over the network again to the server? http://lime-technology.com/wiki/index.php?title=Transferring_Files_Within_the_unRAID_Server
March 5, 201016 yr Author just checked smart data and the drive appears to be failing. I wouldn't think this could be causesd by the cable, could it? Power is good and it's a Linux copy. === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: FAILED! Drive failure expected in less than 24 hours. SAVE ALL DATA. See vendor-specific Attribute list for failed Attributes. SMART Attributes Data Structure revision number: 16 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 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 181 176 021 Pre-fail Always - 7941 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 157 5 Reallocated_Sector_Ct 0x0033 090 090 140 Pre-fail Always FAILING_NOW 875 7 Seek_Error_Rate 0x000e 145 145 051 Old_age Always - 858 9 Power_On_Hours 0x0032 085 085 000 Old_age Always - 11517 10 Spin_Retry_Count 0x0012 100 100 051 Old_age Always - 0 11 Calibration_Retry_Count 0x0012 100 100 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 157 192 Power-Off_Retract_Count 0x0032 172 172 000 Old_age Always - 21437 193 Load_Cycle_Count 0x0032 183 183 000 Old_age Always - 53398 194 Temperature_Celsius 0x0022 123 104 000 Old_age Always - 29 196 Reallocated_Event_Count 0x0032 001 001 000 Old_age Always - 241 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 2 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age Offline - 0
March 6, 201016 yr That disk is gone. Its 'Reallocated_Sector_Ct' is way past the 'failed' treshold. Nothing you can do about it other than replacing it. But, independently of that, you may still have some cable problems you should look into. (not that cables have anything to do with the Reallocated_Sector_Ct). Notice the very high value of the 'Power-Off_Retract_Count'? This shows how many times the disk retracted the heads in emmergency upon unexpected power loss. This normally means a crappy power connection. Also, its 'UDMA_CRC_Error_Count' is not zero. On two occasions it encountered UDMA errors, which normally means a problematic data cable. Of course, I don't know how long you've had that disk. These events may be recent, or they may have happened a long time ago.
Archived
This topic is now archived and is closed to further replies.