Mauvaises performances en écriture d'un réseau RAID10 logiciel de 8 disques SSD

J'ai un serveur avec une carte mère Supermicro X10DRW-i et une matrice RAID10 de 8 SSD KINGSTON SKC400S ; le système d'exploitation est CentOS 6.

  # cat /proc/mdstat 
Personalities : [raid10] [raid1] 

md2 : active raid10 sdj3[9](S) sde3[4] sdi3[8] sdd3[3] sdg3[6] sdf3[5] sdh3[7] sdb3[1] sda3[0]
      3978989568 blocks super 1.1 512K chunks 2 near-copies [8/8] [UUUUUUUU]
      bitmap: 9/30 pages [36KB], 65536KB chunk

-

  # mdadm --detail /dev/md2                
    /dev/md2:
            Version : 1.1
      Creation Time : Wed Feb  8 18:35:14 2017
         Raid Level : raid10
         Array Size : 3978989568 (3794.66 GiB 4074.49 GB)
      Used Dev Size : 994747392 (948.67 GiB 1018.62 GB)
       Raid Devices : 8
      Total Devices : 9
        Persistence : Superblock is persistent

      Intent Bitmap : Internal

        Update Time : Fri Sep 14 15:19:51 2018
              State : active 
     Active Devices : 8
    Working Devices : 9
     Failed Devices : 0
      Spare Devices : 1

             Layout : near=2
         Chunk Size : 512K

               Name : ---------:2  (local to host -------)
               UUID : 8a945a7a:1d43dfb2:cdcf8665:ff607a1b
             Events : 601432

        Number   Major   Minor   RaidDevice State
           0       8        3        0      active sync set-A   /dev/sda3
           1       8       19        1      active sync set-B   /dev/sdb3
           8       8      131        2      active sync set-A   /dev/sdi3
           3       8       51        3      active sync set-B   /dev/sdd3
           4       8       67        4      active sync set-A   /dev/sde3
           5       8       83        5      active sync set-B   /dev/sdf3
           6       8       99        6      active sync set-A   /dev/sdg3
           7       8      115        7      active sync set-B   /dev/sdh3

           9       8      147        -      spare   /dev/sdj3

J'ai remarqué que la vitesse d'écriture est tout simplement terrible, pas même proche des performances des SSD.

# dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=dsync      
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 16.511 s, 65.0 MB/s

La vitesse de lecture est cependant bonne

# hdparm -tT /dev/md2

/dev/md2:
 Timing cached reads:   20240 MB in  1.99 seconds = 10154.24 MB/sec
 Timing buffered disk reads: 3478 MB in  3.00 seconds = 1158.61 MB/sec

Après avoir fait quelques recherches sur le problème, j'ai découvert que j'avais probablement mal configuré le stockage au départ : Le X10DRW-i est équipé d'un Intel C610 qui possède deux contrôleurs SATA séparés, un SATA à 6 ports et un sSATA à 4 ports. Les disques de la matrice sont donc connectés à des contrôleurs différents, et je pense que c'est la cause principale des mauvaises performances. Je n'ai qu'une seule idée pour résoudre ce problème : installer un contrôleur SAS PCIe (probablement AOC-S3008L-L8E) et y connecter des disques SSD.

Je voudrais donc confirmer ce qui suit :

Ai-je raison sur la cause première, ou dois-je revérifier quelque chose ?

Ma solution fonctionnera-t-elle ?

Si je reconnecte les disques au nouveau contrôleur, mon RAID et mes données survivront-ils ? Mes recherches montrent que oui, car les UUID des partitions resteront les mêmes, mais je veux juste être sûr.

Merci à tous par avance.

UPD : iostat -x 1 en effectuant le test dd : https://pastebin.com/aTfRYriU

# hdparm /dev/sda                                    

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 124519/255/63, sectors = 2000409264, start = 0

-

# cat /sys/block/md2/queue/scheduler                 
none

Bien que le planificateur AFAIK soit défini sur les disques physiques :

# cat /sys/block/sda/queue/scheduler 
noop anticipatory [deadline] cfq 

-

smartctl -a (sur les périphériques, pas sur les partitions) : https://pastebin.com/HcBp7gUH

UPD2 :

# dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 14.389 s, 74.6 MB/s

UPD3 :

Je viens de courir fstrim sur la partition / et j'ai obtenu un peu de En effet, la vitesse d'écriture reste trop faible : 227 Mo/s, 162 Mo/s, 112 Mo/s, 341 Mo/s, 202 Mo/s lors de cinq tests consécutifs.