July 23, 20169 yr ... wonder if that could also be causing parity unhappiness? No. It failed a write attempt. This is a hardware issue of some kind. Did you take a look at the wiki I linked? Quite odd. I wake one day and see the same exact thing. I've never seen a red X near my parity drive, but I did perform the diagnostics on it if anyone does want to take a look. Make it easy last 4 digits of SN of drive 6713. I rebooted it once, same thing. I was currently connected to one of my onboard SATA connection, using a reverse break out cable so all the connections where secure. Because I wanted my parity drive back I moved the drive to one of my Dell H310 controllers and it started re-building my parity. Kind of scarey, something blew away my entire parity disk (doing a LONG self test on it now) for reasons I can't tell. I did see write errors in there, so I have to get a 4TB drive anyway. I can go to Best Buy and get robbed or order one online for a difference. An HGST 4TB drive still $159. Sheesh. sun-diagnostics-20160722-2008.zip
July 23, 20169 yr Author Update: Anyone familiar with this one? All I'm trying to do is run a LONG SMART report through the web gui. I did cancel it and may try from the command but I do think the drive may be taking very fast dump on me. Jul 23 15:52:24 SUN sshd[30514]: Did not receive identification string from 192.168.1.104 Condensed my log. Apparently can't find my parity drive. Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: configured for UDMA/133 (device error ignored) Jul 16 10:03:12 SUN kernel: res 61/04:40:c8:2d:2d/00:05:7b:00:00/e0 Emask 0x1 (device error) Jul 16 10:03:12 SUN kernel: ata1.00: error: { ABRT } Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: configured for UDMA/133 (device error ignored) Jul 16 10:03:12 SUN kernel: res 61/04:40:c8:2d:2d/00:05:7b:00:00/e0 Emask 0x1 (device error) Jul 16 10:03:12 SUN kernel: ata1.00: error: { ABRT } Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: configured for UDMA/133 (device error ignored) Jul 16 10:03:12 SUN kernel: res 61/04:40:c8:2d:2d/00:05:7b:00:00/e0 Emask 0x1 (device error) Jul 16 10:03:12 SUN kernel: ata1.00: error: { ABRT } Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: configured for UDMA/133 (device error ignored) Jul 16 10:03:12 SUN kernel: res 61/04:40:c8:2d:2d/00:05:7b:00:00/e0 Emask 0x1 (device error) Jul 16 10:03:12 SUN kernel: ata1.00: error: { ABRT } Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: configured for UDMA/133 (device error ignored) Jul 16 10:03:12 SUN kernel: res 61/04:40:c8:2d:2d/00:05:7b:00:00/e0 Emask 0x1 (device error) Jul 16 10:03:12 SUN kernel: ata1.00: error: { ABRT } Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: failed to enable AA (error_mask=0x1) Jul 16 10:03:12 SUN kernel: ata1.00: configured for UDMA/133 (device error ignored) Jul 16 10:03:12 SUN kernel: blk_update_request: I/O error, dev sdb, sector 2066558408 If it couldn't find disk0 or any drive on that port, why is it trying to write to it? Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558680 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558688 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558696 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558704 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558712 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558720 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558728 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558736 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558744 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558752 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558760 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558768 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558776 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558784 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558792 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558800 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558808 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558816 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558824 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558832 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558840 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558848 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558856 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558864 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558872 Jul 16 10:03:12 SUN kernel: md: disk0 write error, sector=2066558880 I'm doing a long SMART report, but it's been going for over an hour at least and still says %50. Wondering if that's normal.
July 24, 20169 yr Author I have split your support into a separate topic. Ok thanks. Right now I'm doing an exaustive sector by sector check using a utility on another computer. If that passes, then I'm confident that the drive is good, but not the parity. After reviewing the log even more one one day my electric was shutting down and off all day. I do have a UPS, and gives the server enough time to shutdown gracefully, so I'm wondering what the root cause of the issue could be to begin with.
Archived
This topic is now archived and is closed to further replies.