After the rebuild is done look at the syslog to confirm the ATA errors are gone, if in doubt post it.

Where do I look in the syslog or what should I be looking for?

Here is the diagnostics

tower-diagnostics-20170324-1235.zip

Tools -> Syslog

 

if there are still issues they'll probably show up during a parity check/rebuild, so its a good time to look for them, they show in red, and look similar to these:

 

Mar 20 13:16:32 Tower kernel: ata7: hard resetting link
Mar 20 13:16:33 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 20 13:16:33 Tower kernel: ata7.00: NCQ Send/Recv Log not supported
Mar 20 13:16:33 Tower kernel: ata7.00: NCQ Send/Recv Log not supported
Mar 20 13:16:33 Tower kernel: ata7.00: configured for UDMA/133
Mar 20 13:16:33 Tower kernel: ata7: EH complete
Mar 20 13:29:36 Tower kernel: ata7.00: exception Emask 0x12 SAct 0x0 SErr 0x400501 action 0x6 frozen
Mar 20 13:29:36 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Mar 20 13:29:36 Tower kernel: ata7: SError: { RecovData UnrecovData Proto Handshk }
Mar 20 13:29:36 Tower kernel: ata7.00: failed command: READ DMA EXT
Mar 20 13:29:36 Tower kernel: ata7.00: cmd 25/00:40:70:61:85/00:05:09:00:00/e0 tag 30 dma 688128 in
Mar 20 13:29:36 Tower kernel:         res 50/00:00:6f:61:85/00:00:09:00:00/e9 Emask 0x12 (ATA bus error)
Mar 20 13:29:36 Tower kernel: ata7.00: status: { DRDY }
Mar 20 13:29:36 Tower kernel: ata7: hard resetting link
Mar 20 13:29:36 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 20 13:29:36 Tower kernel: ata7.00: NCQ Send/Recv Log not supported
Mar 20 13:29:36 Tower kernel: ata7.00: NCQ Send/Recv Log not supported
Mar 20 13:29:36 Tower kernel: ata7.00: configured for UDMA/133
Mar 20 13:29:36 Tower kernel: ata7: EH complete
Mar 20 13:30:48 Tower kernel: ata7.00: exception Emask 0x12 SAct 0x0 SErr 0x500 action 0x6 frozen
Mar 20 13:30:48 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error
Mar 20 13:30:48 Tower kernel: ata7: SError: { UnrecovData Proto }
Mar 20 13:30:48 Tower kernel: ata7.00: failed command: READ DMA EXT
Mar 20 13:30:48 Tower kernel: ata7.00: cmd 25/00:40:70:17:29/00:05:0a:00:00/e0 tag 5 dma 688128 in
Mar 20 13:30:48 Tower kernel:         res 50/00:00:6f:17:29/00:00:0a:00:00/ea Emask 0x12 (ATA bus error)
Mar 20 13:30:48 Tower kernel: ata7.00: status: { DRDY }

 

Ok, I run a parity check tonight.

 

 

15 hours ago, tunetyme said:

I have 4 drives that have between 2300 and 3000 hours on them?

 

I wasn't sure what you meant, because drives with only 3000 hours are really young.  Drives with 30000 are still in their prime.  I don't think of drives as getting older until they are well over 50000 hours.  I believe I've seen drives with over 70000 hours still going strong, no significant issues.

 

Users tend to replace drives because of size issues, more than age issues, I think.  They outgrow them after awhile.

5 hours ago, RobJ said:

Users tend to replace drives because of size issues, more than age issues, I think.  They outgrow them after awhile.

Despite all the support I have given to users with drive issues, I have never had one fail in unRAID. I have done many replacements though, for size. I have had a few drives fail in other uses during my many years.

 

What I sometimes say about electronics in general is that if it survives infant mortality, it will often be obsolete before it fails.

My main requirement is larger drives. I don't have space to expand my total number of drives. I have had several drives that died for various reasons over the years and it was catastrophic. With the price of storage it is very cheap storage to have a couple of backups. The drives I am pulling out will go into the pool of backup drives. I will start adding some 4 TB drives as needed.