No problems with the controller so far. Rsynced 3.8 TB of data without any dmesg errors so far.
I think the btrfs scrub creates much more io load on the controller.
I will do some stress testing (copy several hundred GB between the connected ssds/hdd, may be in parallel) and let you know if there are errors.
Do you know a good method of stress testing a Sata-Controller?
greetings
Edit:
While doing some stress testing (copy 500GB from sw-raid1 to both ssds in parallel), the ugly error messages pop up several times in dmesg:
The SSDs recover from that and the cp processes are still going on.
Write speeds are limited by read speed of md0 (2xWD Red 6TB):
The write speed drops down to zero, when a hard reset of the link happens.
This happens on both connected SSDs,not in parallel and not on the HDDs so far.
greetings
I think the btrfs scrub creates much more io load on the controller.
I will do some stress testing (copy several hundred GB between the connected ssds/hdd, may be in parallel) and let you know if there are errors.
Do you know a good method of stress testing a Sata-Controller?
greetings
Edit:
While doing some stress testing (copy 500GB from sw-raid1 to both ssds in parallel), the ugly error messages pop up several times in dmesg:
Code:
[177359.815846] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6 frozen
[177359.818370] ata1.00: failed command: WRITE FPDMA QUEUED
[177359.820792] ata1.00: cmd 61/78:08:70:a3:04/00:00:1d:00:00/40 tag 1 ncq dma 6 1440 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time out)
[177359.826247] ata1.00: status: { DRDY }
[177359.828502] ata1: hard resetting link
[177360.145994] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[177360.150489] ata1.00: supports DRM functions and may not be fully accessible
[177360.153733] ata1.00: disabling queued TRIM support
[177360.156187] ata1.00: supports DRM functions and may not be fully accessible
[177360.159228] ata1.00: disabling queued TRIM support
[177360.160830] ata1.00: configured for UDMA/133
[177360.163081] ata1: EH complete
[177394.635885] ata1.00: exception Emask 0x0 SAct 0x40000 SErr 0x0 action 0x6 fr ozen
[177394.638381] ata1.00: failed command: READ FPDMA QUEUED
[177394.640550] ata1.00: cmd 60/08:90:08:08:c0/00:00:00:00:00/40 tag 18 ncq dma 4096 in
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (time out)
[177394.645314] ata1.00: status: { DRDY }
[177394.647351] ata1: hard resetting link
[177394.963135] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[177394.967475] ata1.00: supports DRM functions and may not be fully accessible
[177394.970766] ata1.00: disabling queued TRIM support
[177394.973283] ata1.00: supports DRM functions and may not be fully accessible
[177394.979736] ata1.00: disabling queued TRIM support
[177394.981241] ata1.00: configured for UDMA/133
[177394.986826] ata1: EH complete
The SSDs recover from that and the cp processes are still going on.
Write speeds are limited by read speed of md0 (2xWD Red 6TB):
Code:
avg-cpu: %user %nice %system %iowait %steal %idle
0.88 0.00 26.83 23.29 0.00 49.00
Device: tps MB_read/s MB_wrtn/s MB_read MB_wrtn
mtdblock0 0.00 0.00 0.00 0 0
mtdblock1 0.00 0.00 0.00 0 0
mtdblock2 0.00 0.00 0.00 0 0
mmcblk1 35.00 0.15 0.00 0 0
mmcblk1boot1 0.00 0.00 0.00 0 0
mmcblk1boot0 0.00 0.00 0.00 0 0
mmcblk0 0.00 0.00 0.00 0 0
sdc 202.20 0.00 102.58 0 512
sdd 413.20 102.85 0.00 514 0
sdb 454.00 112.99 0.00 564 0
sda 372.20 0.00 118.66 0 593
md0 864.60 215.84 0.00 1079 0
The write speed drops down to zero, when a hard reset of the link happens.
This happens on both connected SSDs,not in parallel and not on the HDDs so far.
greetings