July 2, 20179 yr An automatic parity check is currently running. It appears to be taking longer than it did when I ran it about 2 weeks ago when I put a new drive in the system. The new drive has had 336 errors. I thought I put the drive through it's paces at install by doing 3 pre clears and then doing a parity check after the drive was installed and started being used. Smart information for the drive shows that 140 sectors were reallocated and the raw read error rate is 51.. Hours of operation shows 423 (17d, 15h). I'm thinking of going and grabbing a new drive and subbing it out and sending the one with errors to the maker (assuming they will RMA it). Is this the right course of action or am I over reacting? BTW this parity check seems to be taking longer than the one I did after installing the drive. The previous one took less than 24 hours. This one is at 29 hours at 86.1%. Probably means nothing but just seems odd. I'd pass on full logs, but currently the system doesn't seem to want to spit it out. The webpage hangs when I try to look at the system log. When I click the log which appears to just show the last X amount of lines from the log it shows disk errors all happened a couple hours ago. (Curious too, I noticed the 2 dockers that run regularly (Crashplan and Resilio Sync) appeared to still be running. Shouldn't the system turn those off during a priority check? I'm thinking they might make the Priority check take longer since they would be accessing the drives. I've stopped both of the dockers just in case and it honestly seems to have sped up the parity check.) Here's the limited logs I can see right this second. (What is making the webpage freeze when I try to get the logs, I'm not sure. Even on a fresh web browser with no other pages open it appears to be stuck.) Anyway here is what I can see at the moment. Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826280 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826288 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826296 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826304 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826312 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826320 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826328 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826336 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826344 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826352 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826360 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826368 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826376 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826384 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826392 Jul 2 03:33:59 Tower kernel: md: disk6 read error, sector=5622826400 Jul 2 04:51:57 Tower kernel: vethf2a8af2: renamed from eth0 Jul 2 04:51:57 Tower kernel: docker0: port 1(vethbf371a5) entered disabled state Jul 2 04:51:57 Tower kernel: docker0: port 1(vethbf371a5) entered disabled state Jul 2 04:51:57 Tower kernel: device vethbf371a5 left promiscuous mode Jul 2 04:51:57 Tower kernel: docker0: port 1(vethbf371a5) entered disabled state Jul 2 04:52:08 Tower kernel: veth94edc8c: renamed from eth0 Jul 2 04:52:08 Tower kernel: docker0: port 2(vethf5a059d) entered disabled state Jul 2 04:52:08 Tower kernel: docker0: port 2(vethf5a059d) entered disabled state Jul 2 04:52:08 Tower kernel: device vethf5a059d left promiscuous mode Jul 2 04:52:08 Tower kernel: docker0: port 2(vethf5a059d) entered disabled state Jul 2 04:52:10 Tower ntpd[1507]: Deleting interface #4 docker0, 172.17.0.1#123, interface stats: received=0, sent=0, dropped=0, active_time=501317 secs Jul 2 05:11:28 Tower emhttp: err: sendFile: sendfile /usr/local/emhttp/plugins/preclear.disk/assets/tooltipster.bundle.min.js: Broken pipe Jul 2 05:12:10 Tower emhttp: err: sendFile: sendfile /usr/local/emhttp/plugins/preclear.disk/assets/tooltipster.bundle.min.js: Broken pipe Jul 2 05:22:11 Tower kernel: mdcmd (121): spindown 1 Jul 2 05:22:13 Tower kernel: mdcmd (122): spindown 2 Jul 2 05:22:16 Tower kernel: mdcmd (123): spindown 3 Jul 2 05:22:18 Tower kernel: mdcmd (124): spindown 4 Jul 2 05:22:19 Tower kernel: mdcmd (125): spindown 5 Jul 2 05:22:21 Tower kernel: mdcmd (126): spindown 6
July 2, 20179 yr Author Not yet. I was waiting until the parity check finished to do anything else with the system.
July 2, 20179 yr Author Oh and odd thing... Parity check is at 91.6% but all the data drives have spun down?? Seems like they should be spun up if it is suppose to be checking Parity.
July 2, 20179 yr Community Expert If that parity check is at 91+%, I would imaging that it past all of the data that you have stored on the array. If it does move in the next thirty to forty minutes, I would terminate it. You know you have a problem at this point and that is the principal reason for the periodic parity check anyway.
July 2, 20179 yr Author It's pumping along now since I stopped the 2 dockers. At 93.8. I'll run a diagnostic once it finishes and post it.
July 2, 20179 yr Author Wow the extended self test is taking a long time. The short test is attached here at least. Overall health test passed. but it did have those errors. WDC_WD30EFRX.txt
July 2, 20179 yr 19 minutes ago, tnorman said: Wow the extended self test is taking a long time. The short test is attached here at least. Overall health test passed. but it did have those errors. WDC_WD30EFRX.txt There are no concerning attributes in this SMART report. Looks very healthy. Only 20 days old or so. Whatever read errors the OS encountered do not appear to have been caused by an issue with the drive itself. The extended test will take a while. It is reading every sector. I would mention that parity checks do not disable dockers, and that nothing a docker is doing should impact the ability of the parity check to do its thing (although it could cause a slowdown). The parity check operations are happening at a low level, and no file locks or access permissions should come into play. It is only reading from the data drives. You might also try running the diskspeed.sh script, and see if there are any performance-related issues with the drive, that might not be detected by the tests you are running. There could be some interaction between the dockers you are running and unRAID. It is very strange that the parity check became "unstuck" when the Dockers came down. The Marvell controller chips have created some problems with VMs. The best course is to post your diagnostics file, and see if one of the experts here can infer what might be happening. The syslog is not maintained across boots, so you really need to capture AFTER something weird happens and BEFORE you reboot, so that the log entries in and around the event are included. One more point - the most common problem people have are cabling issues. Although the problem you are having is not screaming "cable problem", I would not be surprised to see the root caused ultimately traced to that. I would therefore power down and check your cable connections to the drive and rule it out.
July 2, 20179 yr Author I'll check into the cables. I did have to use a fairly long sata cable to the drive. The motherboard has connections on the bottom corner and the drive is at the top of the tower case. So I was worried initially but since it went thru preclears and an initial parity check I figure all was good. Maybe It wiggled loose or something. I think the slow down for the parity check was just because of dockers running. One is Crashplan and it is uploading a ton so it is constantly running right now. Probably the extra disk access from that just slowed down the parity check. Just guessing tho. My concern is a fairly new drive with reallocated sector count. I know some will happen, but 140 reallocated sectors seems large to me. The extended test should give it a thorough run thru if it is checking every sector all over again. Thanks for the help. I'll do the diskspeed.sp once I finish the extended test.
July 2, 20179 yr Community Expert 2 minutes ago, tnorman said: My concern is a fairly new drive with reallocated sector count. I know some will happen, but 140 reallocated sectors seems large to me. The extended test should give it a thorough run thru if it is checking every sector all over again. I would not be happy with that value on a newish drive, and would consider it a candidate for a RMA. You certainly want it replaced if it continues to increase.
July 2, 20179 yr The smart report you provided has no reallocated sectors. Is this the same drive? ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 78 3 Spin_Up_Time 0x0027 188 182 021 Pre-fail Always - 5575 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 27 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 426 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 3 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 0 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 150 194 Temperature_Celsius 0x0022 125 111 000 Old_age Always - 25 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
July 2, 20179 yr Community Expert 29 minutes ago, tnorman said: I'll check into the cables. I did have to use a fairly long sata cable to the drive. The motherboard has connections on the bottom corner and the drive is at the top of the tower case. So I was worried initially but since it went thru preclears and an initial parity check I figure all was good. Maybe It wiggled loose or something. Be sure to read this about WD Drives and latching cables: https://support.wdc.com/knowledgebase/answer.aspx?ID=10477 And did you try to get a diagnostics file? 'Tools' >>> 'Diagnostics'
July 2, 20179 yr Author 25 minutes ago, bjp999 said: The smart report you provided has no reallocated sectors. Is this the same drive? You are right. I was totally reading it wrong. I saw the 140 under Thresh and somehow thought that was the count. I have no idea how I did that. Slap my forehead moment. I was able to get the system log out. Long weekend and I'm dead tired today. Sort of freaked out when I initially found there was an error during parity check. I forgot I could download the log or telnet in and get part of it off. I think the log is so huge that http sort of barfed and assumed nothing was happened after X seconds passed. In Chrome and MS Edge it kept wanting to kill the process going on. I'm just guessing at that since I reopened Opera browser which was my last attempt to get the log and there it was when I opened the browser. I'll check into the cables. I did have to use a fairly long sata cable to the drive. The motherboard has connections on the bottom corner and the drive is at the top of the tower case. So I was worried initially but since it went thru preclears and an initial parity check I figure all was good. Maybe It wiggled loose or didn't like me putting the case back together last week. I think the slow down for the parity check was just because of dockers running. One is Crashplan and it is uploading a ton so it is constantly running. Probably the extra disk access from that just slowed down the parity check. Thanks for the help. I'll do the diskspeed.sp once I finish the extended test. I've attached the syslog.txt which has the errors for the disk in it. there are 2 other sys log files if desired. Let me know if those will help. But I agree I'm not overly concerned with read errors. My initial thought was that there were sector errors, but it doesn't look like it was the issue. syslog.txt
July 2, 20179 yr 13 minutes ago, tnorman said: You are right. I was totally reading it wrong. I saw the 140 under Thresh and somehow thought that was the count. I have no idea how I did that. Slap my forehead moment. I was able to get the system log out. Long weekend and I'm dead tired today. Sort of freaked out when I initially found there was an error during parity check. I forgot I could download the log or telnet in and get part of it off. I think the log is so huge that http sort of barfed and assumed nothing was happened after X seconds passed. In Chrome and MS Edge it kept wanting to kill the process going on. I'm just guessing at that since I reopened Opera browser which was my last attempt to get the log and there it was when I opened the browser. I'll check into the cables. I did have to use a fairly long sata cable to the drive. The motherboard has connections on the bottom corner and the drive is at the top of the tower case. So I was worried initially but since it went thru preclears and an initial parity check I figure all was good. Maybe It wiggled loose or didn't like me putting the case back together last week. I think the slow down for the parity check was just because of dockers running. One is Crashplan and it is uploading a ton so it is constantly running. Probably the extra disk access from that just slowed down the parity check. Thanks for the help. I'll do the diskspeed.sp once I finish the extended test. I've attached the syslog.txt which has the errors for the disk in it. there are 2 other sys log files if desired. Let me know if those will help. But I agree I'm not overly concerned with read errors. My initial thought was that there were sector errors, but it doesn't look like it was the issue. syslog.txt I am not the foremost expert on syslogs, but here is my interpretation. Jul 2 03:33:56 Tower kernel: ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jul 2 03:33:56 Tower kernel: ata6.00: irq_stat 0x40000001 Jul 2 03:33:56 Tower kernel: ata6.00: failed command: READ DMA EXT Jul 2 03:33:56 Tower kernel: ata6.00: cmd 25/00:40:68:7b:25/00:05:4f:01:00/e0 tag 15 dma 688128 in Jul 2 03:33:56 Tower kernel: res 51/40:cf:d8:7c:25/00:03:4f:01:00/e0 Emask 0x9 (media error) Jul 2 03:33:56 Tower kernel: ata6.00: status: { DRDY ERR } Jul 2 03:33:56 Tower kernel: ata6.00: error: { UNC } Jul 2 03:33:56 Tower kernel: ata6.00: configured for UDMA/133 Jul 2 03:33:56 Tower kernel: sd 6:0:0:0: [sdg] tag#15 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 Jul 2 03:33:56 Tower kernel: sd 6:0:0:0: [sdg] tag#15 Sense Key : 0x3 [current] Jul 2 03:33:56 Tower kernel: sd 6:0:0:0: [sdg] tag#15 ASC=0x11 ASCQ=0x4 Jul 2 03:33:56 Tower kernel: sd 6:0:0:0: [sdg] tag#15 CDB: opcode=0x88 88 00 00 00 00 01 4f 25 7b 68 00 00 05 40 00 00 You see 6th line says "DRDY ERR". I believe that means that the drive is not ready, meaning not accessible. That is likely due to an intermittent connection (i.e., bad cable).
July 3, 20179 yr Author The extended test finished with no real other information to provide. No more read errors so far. I did notice the sata cable was at a slight (very slight) angle, so I pushed it firmly on.
July 3, 20179 yr Community Expert Is that cable firmly seated on the drive? It should have some resistance to removal as you gently pull on it and then that resistance disappears as the connector disconnects. (There should be a couple plastic nibs inside of the connector on the cable to provide that resistance. I have found that it is difficult to actually see them...) If you don't feel that resistance, replace the cable with one that does.
Archived
This topic is now archived and is closed to further replies.