Hello;

I'm running unRaid 4.3.3, on a custom built PC, from different bits and pieces. I've had it for more than 1 year now, and I thought of it to be stable. Last night I have triggered a parity check across all my drives, having noticed that the last full parity check had taken place in June 2008.

The parity check returned no errors, however reviewing the syslog I found a few messages which got me worried. I attach them below.

I have a couple of questions:

- Is it possible that such issues may hide actually parity errors and loss of of data integrity?  If that is the case, I can't really tell anymore if my data is good or bad. That's terrible.

- are there counter measures to prevent/fix this problem?

Thank you for your comments,

HG

 

Jan  4 17:20:52 Tower logger: /etc/rc.d/rc.inet1:  /sbin/route add default gw 192.168.20.1 metric 1

Jan  4 17:20:52 Tower ifplugd(eth0)[1547]: Program executed successfully.

Jan  5 00:10:14 Tower kernel: mdcmd (2729): check

Jan  5 00:10:14 Tower kernel: md: recovery thread got woken up ...

Jan  5 00:10:14 Tower kernel: md: recovery thread checking parity...

Jan  5 00:10:14 Tower kernel: md: using 1152k window, over a total of 312571192 blocks.

Jan  5 00:11:58 Tower in.telnetd[9497]: connect from 192.168.20.177 (192.168.20.177)

Jan  5 00:12:20 Tower login[9548]: ROOT LOGIN  on `pts/0' from `192.168.20.177'

Jan  5 02:20:34 Tower kernel: hdh: dma_intr: bad DMA status (dma_stat=75)

Jan  5 02:20:34 Tower kernel: hdh: dma_intr: status=0x50 { DriveReady SeekComplete}

Jan  5 02:20:34 Tower kernel: ide: failed opcode was: unknown

Jan  5 02:28:48 Tower kernel: hde: dma_intr: bad DMA status (dma_stat=75)

Jan  5 02:28:48 Tower kernel: hde: dma_intr: status=0x50 { DriveReady SeekComplete}

Jan  5 02:28:48 Tower kernel: ide: failed opcode was: unknown

Jan  5 03:27:25 Tower kernel: md: sync done. time=11831sec rate=26419K/sec

Jan  5 03:27:25 Tower kernel: md: recovery thread sync completion status: 0

Jan  5 06:56:53 Tower in.telnetd[30736]: connect from 192.168.20.177 (192.168.20.177)

Jan  5 06:57:14 Tower login[30737]: ROOT LOGIN  on `pts/0' from `192.168.20.177'

 

 

The parity check returned no errors, however reviewing the syslog I found a few messages which got me worried. I attach them below.

I have a couple of questions:

- Is it possible that such issues may hide actually parity errors and loss of of data integrity?  If that is the case, I can't really tell anymore if my data is good or bad. That's terrible.

- are there counter measures to prevent/fix this problem?

 

Your parity check returned no errors.  I would like to caution you as well as others not to suspect errors or data damage without a true indication of such.  I only know of one case where errors caused damage, and they were true read errors, fully reported as such, AND they occurred during a drive rebuild.  You had both no drive errors reported on the Web Management page, and no parity errors reported in the parity check summary, so all is fine with your data.

 

As to the errors, they aren't good, but they were reported and handled, nothing more to do but keep an eye on those 2 drives.  I would obtain a SMART report for each (hde and hdh), but this was probably not a drive issue.  Perhaps a cable or controller issue?