February 12Feb 12 Hi allI got a notification from my sever a couple of days ago that disk3 is in error state (disk dsbl), along with another notification stating that the array has 1 disk with read errors (disk3 - errors 16). I've run a short SMART test with no errors, and now the extended test is running. Looking at disk 3's attributes I see this:To my untrained eye nothing looks horrendously abnormal and none of the attributes has 16 errors. The only line that's highlighted is the UDMA CRC error count, but in my experience previously that's just issued a warning and not disabled the drive. Has the behaviour changed in UnRAID or do I need to keep looking for the cause of the disk being disabled?Cheers Edited February 12Feb 12 by CurlyBen
February 12Feb 12 11 minutes ago, CurlyBen said:UDMA CRC error count, but in my experience previously that's just issued a warning and not disabled the driveIf the count gets high enough or grows frequently, it can cause a drive to be disabled. This has happened on two of my HDDs in the past. In both cases, the UDMA CRC error count was over 1100 and growing frequently before they became disabled. This usually happened when backing up PCs to the Unraid array. I ended up rebuilding both drives onto themselves as there was nothing inherently wrong with the drive. These errors are usually the result of a bad or loose SATA/SAS cable or MB/HBA port. The drives were fine after rebuild when I swapped cables or attached them to a different HBA port.
February 12Feb 12 Community Expert UDMA CRC doesn't disable a disk, it is just a symptom of something that might disable a disk.If a write fails to a disk, it is disabled, no matter the cause, because the failed write makes it out-of-sync with parity.Connection problems may or may not cause UDMA CRC. If the disk never receives the data to checksum, it can't CRC. But it might disable the disk because the write fails. And, if the connection causes the data to not checksum, it is a CRC error, but it might not disable the disk since the data is resent.
February 12Feb 12 Author 10 minutes ago, Hoopster said:If the count gets high enough or grows frequently, it can cause a drive to be disabled. This has happened on two of my HDDs in the past. In both cases, the UDMA CRC error count was over 1100 and growing frequently before they became disabled. This usually happened when backing up PCs to the Unraid array. I ended up rebuilding both drives onto themselves as there was nothing inherently wrong with the drive. These errors are usually the result of a bad or loose SATA/SAS cable or MB/HBA port. The drives were fine after rebuild when I swapped cables or attached them to a different HBA port.Interesting. I've only got a CRC error count of 8, so nowhere near those numbers, but useful to know that I can't entirely discount them as the cause.5 minutes ago, trurl said:UDMA CRC doesn't disable a disk, it is just a symptom of something that might disable a disk.If a write fails to a disk, it is disabled, no matter the cause, because the failed write makes it out-of-sync with parity.Connection problems may or may not cause UDMA CRC. If the disk never receives the data to checksum, it can't CRC. But it might disable the disk because the write fails. And, if the connection causes the data to not checksum, it is a CRC error, but it might not disable the disk since the data is resent.From the notifications I've had the disk is disabled due to a read error rather than a write error. Hopefully the extended SMART test will throw a little more light on the issue!
February 12Feb 12 Community Expert 1 hour ago, CurlyBen said:From the notifications I've had the disk is disabled due to a read error rather than a write error. Hopefully the extended SMART test will throw a little more light on the issue!If Unraid can't read a disk, it might try to write the calculated data back to the disk, and if that write fails, the disk is disabled.
February 13Feb 13 Author 9 hours ago, trurl said:If Unraid can't read a disk, it might try to write the calculated data back to the disk, and if that write fails, the disk is disabled.It looks like that might be what's happened, I've attached the diagnostics file but the key bit seems to be here and the read errors precede the write errors:Feb 8 02:04:46 Tower kernel: mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00)Feb 8 02:04:46 Tower kernel: sd 10:0:2:0: [sde] tag#2779 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3sFeb 8 02:04:46 Tower kernel: sd 10:0:2:0: [sde] tag#2779 Sense Key : 0x2 [current]Feb 8 02:04:46 Tower kernel: sd 10:0:2:0: [sde] tag#2779 ASC=0x4 ASCQ=0x0Feb 8 02:04:46 Tower kernel: sd 10:0:2:0: [sde] tag#2779 CDB: opcode=0x88 88 00 00 00 00 01 3c 99 84 18 00 00 00 40 00 00Feb 8 02:04:46 Tower kernel: I/O error, dev sde, sector 5311661080 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661016Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661024Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661032Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661040Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661048Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661056Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661064Feb 8 02:04:46 Tower kernel: md: disk3 read error, sector=5311661072Feb 8 02:04:47 Tower kernel: sd 10:0:2:0: [sde] tag#2779 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0sFeb 8 02:04:47 Tower kernel: sd 10:0:2:0: [sde] tag#2779 Sense Key : 0x2 [current]Feb 8 02:04:47 Tower kernel: sd 10:0:2:0: [sde] tag#2779 ASC=0x4 ASCQ=0x0Feb 8 02:04:47 Tower kernel: sd 10:0:2:0: [sde] tag#2779 CDB: opcode=0x8a 8a 00 00 00 00 01 3c 99 84 18 00 00 00 40 00 00Feb 8 02:04:47 Tower kernel: I/O error, dev sde, sector 5311661080 op 0x1:(WRITE) flags 0x0 phys_seg 8 prio class 0Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661016Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661024Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661032Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661040Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661048Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661056Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661064Feb 8 02:04:47 Tower kernel: md: disk3 write error, sector=5311661072The extended SMART test passed, so I think I'll re-enable the drive. I've ordered two new drives so when they arrive I'll retire this drive to be used as a bit of a dumping ground rather than part of the array. This is where I'd really like multiple arrays - a high value array with my irreplaceable data and newest drives, plus a second array with older drives, which may have thrown an error or two, but which only holds films, music and other replaceable media (but still with a parity drive so a single drive failure isn't a big deal). tower-diagnostics-20260213-0901.zip Edited February 13Feb 13 by CurlyBen
February 13Feb 13 Author 1 hour ago, JorgeB said:It would be good to replace the SATA cable before rebuilding.Annoyingly my server is half an hour away and I don't know if that drive is on a SATA-SATA cable or SAS-SATA!This might be a good time to rethink how I'm allocating drives anyway. A number of my array drives are 5+ years old now.
February 14Feb 14 Community Expert 19 hours ago, CurlyBen said:Annoyingly my server is half an hour away and I don't know if that drive is on a SATA-SATA cable or SAS-SATA!As a service man from the Tube-era of TV, take both with you when you go!
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.