March 31, 20251 yr Last night being the first of the month my server started its monthly parity check. When i woke up this morning one of my drives (a seagate exos 16tb drive) was marked with a red X instead of the usual green ball and it looks like that parity check paused about an hour into the run. Ive checked the disk log info and its showing the following: Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2679 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2679 Sense Key : 0x2 [current] Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2679 ASC=0x4 ASCQ=0x0 Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2679 CDB: opcode=0x8a 8a 00 00 00 00 00 6e 7f 7c 30 00 00 04 00 00 00 Apr 1 01:08:02 THEBURROW kernel: I/O error, dev sde, sector 1853848624 op 0x1:(WRITE) flags 0x0 phys_seg 128 prio class 2 I ran a smart report on the drive and it came back with zero errors (attached to post) Looking at the system log (also attached) and it appeared the parity check kicked off ok at midnight but then at 1:08am filled the log with read errors on the drive in question; Apr 1 01:08:02 THEBURROW kernel: mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) Apr 1 01:08:02 THEBURROW kernel: mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) Apr 1 01:08:02 THEBURROW kernel: mpt2sas_cm0: log_info(0x31110d00): originator(PL), code(0x11), sub_code(0x0d00) Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2653 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2653 Sense Key : 0x2 [current] Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2653 ASC=0x4 ASCQ=0x0 Apr 1 01:08:02 THEBURROW kernel: sd 3:0:3:0: [sde] tag#2653 CDB: opcode=0x88 88 00 00 00 00 00 6e 7f 88 30 00 00 04 00 00 00 Apr 1 01:08:02 THEBURROW kernel: I/O error, dev sde, sector 1853851696 op 0x0:(READ) flags 0x0 phys_seg 128 prio class 2 Apr 1 01:08:02 THEBURROW kernel: md: disk1 read error, sector=1853851632 Apr 1 01:08:02 THEBURROW kernel: md: disk1 read error, sector=1853851640 Apr 1 01:08:02 THEBURROW kernel: md: disk1 read error, sector=1853851648 A couple of weeks ago I replaced an 8tb drive in the array with a 18tb drive and it successfully rebuilt the drive into the array so this exos drive has been working fine up till now as far as i can tell. Any advice on what to try? could it be a disk issue if the SMART is coming back clean? could it be something else i need to check? The drives are hooked up to an M1015 HBA via a fan out cable which has been working fine in the system for 12+ years. theburrow-smart-20250401-0733.zip theburrow-syslog-20250331-2050.zip
March 31, 20251 yr Author hey trurl - diagnostics attached now.. forgot that one sorry theburrow-diagnostics-20250401-0841.zip
March 31, 20251 yr Community Expert It takes a write error to make the disk out-of-sync and disabled, which happened immediately after those read errors. Disk looks OK, seems like a problem communicating with the disk. Check connections. Emulated disk is mounted, should be OK to rebuild on top.
March 31, 20251 yr Author 42 minutes ago, trurl said: It takes a write error to make the disk out-of-sync and disabled, which happened immediately after those read errors. Disk looks OK, seems like a problem communicating with the disk. Check connections. Emulated disk is mounted, should be OK to rebuild on top. hmmm ok maybe i bumped a cable when i had it open replacing the old drive.. although that should have shown during the rebuild of the old drive to the new one i would have thought?? Ill power down and check all the cables etc... so when i power it back up will it recognize the drive and automatically add it to the array or will i have to do a rebuild onto that same disabled drive?
April 1, 20251 yr Community Expert Solution 1 hour ago, Talos said: have to do a rebuild onto that same disabled drive https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself Or onto a new drive.
April 1, 20251 yr Author 1 hour ago, trurl said: https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself Or onto a new drive. Awesome thanks mate... I powered down, checked all the cables etc (everything appeared to be solidly connected but we will see i guess), powered it backup and am now starting that rebuild process.. hopefully ill just report back tomorrow when its all done
April 2, 20251 yr Author Thanks for the help trurl - its just finished rebuilding onto the drive and all data appears to be ok. Passed with zero warnings or errors this time.
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.