[6.8.3] VERY slow move from Cache to array

The two actions are not equivalent and you should expect writing to the array to always be slower than a parity check.    You might want to read this section from the online documentation to get an insight into why this is the case.

The speeds you quote are not atypical for writing to the parity protected array   Do you have the “Turbo Write” mode active as this may well give faster write speeds (albeit at the expense of keeping all drives spinning).

 

I don't have Turbo write enabled right now. I'l enable it after the copy. 

 

But I'm getting these errors in the system log now:

 

Mar 8 11:31:22 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
Mar 8 11:31:22 GIBSON kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT3._GTF, AE_NOT_FOUND (20180810/psparse-514)
Mar 8 11:31:22 GIBSON kernel: ata4.00: configured for UDMA/133
Mar 8 11:31:22 GIBSON kernel: ata4: EH complete
Mar 8 11:33:21 GIBSON kernel: ata4.00: exception Emask 0x10 SAct 0x1f0 SErr 0x400100 action 0x6 frozen
Mar 8 11:33:21 GIBSON kernel: ata4.00: irq_stat 0x08000000, interface fatal error
Mar 8 11:33:21 GIBSON kernel: ata4: SError: { UnrecovData Handshk }
Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED
Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:20:88:ef:9d/05:00:b4:01:00/40 tag 4 ncq dma 688128 out
Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error)
Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY }
Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED
Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:28:c8:f4:9d/05:00:b4:01:00/40 tag 5 ncq dma 688128 out
Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error)
Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY }
Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED
Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:30:08:fa:9d/05:00:b4:01:00/40 tag 6 ncq dma 688128 out
Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error)
Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY }
Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED
Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/40:38:48:ff:9d/05:00:b4:01:00/40 tag 7 ncq dma 688128 out
Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error)
Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY }
Mar 8 11:33:21 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED
Mar 8 11:33:21 GIBSON kernel: ata4.00: cmd 61/08:40:88:04:9e/00:00:b4:01:00/40 tag 8 ncq dma 4096 out
Mar 8 11:33:21 GIBSON kernel: res 40/00:40:88:04:9e/00:00:b4:01:00/40 Emask 0x10 (ATA bus error)
Mar 8 11:33:21 GIBSON kernel: ata4.00: status: { DRDY }
Mar 8 11:33:21 GIBSON kernel: ata4: hard resetting link
Mar 8 11:33:21 GIBSON kernel: ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Mar 8 11:33:21 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
Mar 8 11:33:21 GIBSON kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT3._GTF, AE_NOT_FOUND (20180810/psparse-514)
Mar 8 11:33:21 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
Mar 8 11:33:21 GIBSON kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.PRT3._GTF, AE_NOT_FOUND (20180810/psparse-514)
Mar 8 11:33:21 GIBSON kernel: ata4.00: configured for UDMA/133
Mar 8 11:33:21 GIBSON kernel: ata4: EH complete
Mar 8 11:33:29 GIBSON webGUI: Successful login user root from 192.168.1.158

 

BIOS IS ACTUALLY UP TO DATE! Tried flashing, have same revision.

Edited March 8, 2020 by urbanracer34

Those ata errors on disk2 are a hardware problem, likely a connection issue, check/replace both cables.

Cables appear to be secure. Can a SATA cable really go bad all of a sudden?

 

I did another move operation this morning (a much smaller one,) with no errors in the log.

Edited March 9, 2020 by urbanracer34

24 minutes ago, urbanracer34 said:

Can a SATA cable really go bad all of a sudden?

Yes, and it won't hurt to replace them.

Ok. I currently have a lot on my head at the moment (don't want to get into it,) so I might not get to it for a while.