My monthly parity check is at 80% and has apparently noted 46 errors thus far, all on disk #10.  Main screen currently shows 0 parity sync errors.  One curious thing.  I checked the log, and apparently the errors all occurred at once and all are sequential sectors, divisible by 8.  (Log excerpt below)

 

<the event obviously started here>

^{Nov  1 13:54:36 tower kernel: ata19.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6}

^{Nov  1 13:54:36 tower kernel: ata19.00: edma_err_cause=00000084 pp_flags=00000001, dev error, EDMA self-disable}

^{Nov  1 13:54:36 tower kernel: ata19.00: failed command: READ DMA EXT}

^{Nov  1 13:54:36 tower kernel: ata19.00: cmd 25/00:00:78:63:73/00:04:a9:00:00/e0 tag 0 dma 524288 in}

^{Nov  1 13:54:36 tower kernel:          res 51/40:70:08:66:73/40:01:a9:00:00/e0 Emask 0x9 (media error)}

^{Nov  1 13:54:36 tower kernel: ata19.00: status: { DRDY ERR }}

^{Nov  1 13:54:36 tower kernel: ata19.00: error: { UNC }}

^{Nov  1 13:54:36 tower kernel: ata19: hard resetting link}

^{Nov  1 13:54:36 tower kernel: ata19: SATA link up 3.0 Gbps (SStatus 123 SControl 300)}

^{Nov  1 13:54:36 tower kernel: ata19.00: configured for UDMA/133}

^{Nov  1 13:54:36 tower kernel: sd 21:0:0:0: [sdl] Unhandled sense code}

^{Nov  1 13:54:36 tower kernel: sd 21:0:0:0: [sdl]} 

^{Nov  1 13:54:36 tower kernel: Result: hostbyte=0x00 driverbyte=0x08}

^{Nov  1 13:54:36 tower kernel: sd 21:0:0:0: [sdl]} 

^{Nov  1 13:54:36 tower kernel: Sense Key : 0x3 [current] [descriptor]}

^{Nov  1 13:54:36 tower kernel: Descriptor sense data with sense descriptors (in hex):}

^{Nov  1 13:54:36 tower kernel:        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00}

^{Nov  1 13:54:36 tower kernel:        a9 73 66 08}

^{Nov  1 13:54:36 tower kernel: sd 21:0:0:0: [sdl]} 

^{Nov  1 13:54:36 tower kernel: ASC=0x11 ASCQ=0x4}

^{Nov  1 13:54:36 tower kernel: sd 21:0:0:0: [sdl] CDB:}

^{Nov  1 13:54:36 tower kernel: cdb[0]=0x28: 28 00 a9 73 63 78 00 04 00 00}

^{Nov  1 13:54:36 tower kernel: end_request: I/O error, dev sdl, sector 2842912264}

^{Nov  1 13:54:36 tower kernel: ata19: EH complete}

 

^{<partial list of sector numbers below>}

 

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912488}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912496}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912504}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912512}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912520}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912528}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912536}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912544}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912552}

^{Nov 1 13:54:36 tower kernel: md: disk10 read error, sector=2842912560}

 

This is my first error found in several years of running Unraid.  In reading previous posts, I already know to do a smart report when the parity check is complete.  I'm just guessing that since no parity sync errors are shown, this is strictly an issue with disk#10.  I'll update this post with the smart report tonight or tomorrow, but would welcome any advice regarding how to most safely proceed.  Currently, "Correct any parity check errors by writing the parity disk with corrected parity" is UNCHECKED.

 

My questions:

 

Is it significant that the sector numbers are multiples of 8?

Safest way to proceed?

When the test finishes, run it again.    When a read error occurs, my understanding is that UnRAID writes the sector again with the correct data (reconstructed from the other disks).    Since no write errors occurred (i.e. the disk wasn't red-balled and disabled), they should have been okay.

 

So on a subsequent test everything should be fine.  If not, then you have an issue with that disk.

 

Ran a short SMART report- nothing noteworthy.  The main screen reports, _{"Last checked on Fri Nov 1 19:20:27 2013 EDT, finding 0 errors."} and the smart report showed zero reallocated sectors, with an overall health rating of "passed"...for whatever that's worth. 

 

I'll uncheck the _{"Correct any Parity-Check errors by writing the Parity disk with corrected parity."} box and restart the check this evening. 

 

Thanks, Gary.

Second parity check completed with zero errors.  Second SMART report still shows 0 reallocated sectors.  I'll consider everything okay but will keep an eye on disk #10.  All-in-all, a reassuring first encounter with my first error condition!  Thanks again, Gary.