Salut, si tu veux quelques benchs de differents ssd en 4k + fsync, voici un article interessant sur ceph et les disques ssd pour le journal.
https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is...
----- Mail original ----- De: "Julien Escario" julien.escario@altinea.fr À: "French SysAdmin Group" frsag@frsag.org Envoyé: Jeudi 12 Avril 2018 16:29:18 Objet: Re: [FRsAG] Latences typiques des SSD
Le 12/04/2018 à 11:54, Julien Escario a écrit :
Le 10/04/2018 à 22:14, Nicolas Charles a écrit :
Bonsoir,
Ce test est un test du pire cas possible pour un SSD: écrire des blocs de 4K, avec un oflag=dsync, ça force le SSD a effectivement commiter l'écriture, par tranche de 4Ko.
Oui, c'est l'idée : travailler sur le worst-case pour voir jusqu'où je peux alle r. D'autant que dans mes mesures, les IO en écritures tournent souvent autour de 4 ou 8k et si je fais du sync=always, finalement, je ne suis pas si éloigné de mon use-case.
Avec un bs=512k, le resultat devrait être bien meilleur.
Bonne idée pour vérifier l'hypothèse, quelques résultats avec le 850PRO (j'ai ajusté à 10k blocs pour réduire les temps de test) :
dd if=/dev/zero of=/dev/sdc bs=4k count=10000 oflag=dsync 40960000 bytes (41 MB, 39 MiB) copied, 9,58961 s, 4,3 MB/s
Update : j'ai fini par obtenir des résultats plutôt corrects avec la commande : # echo temporary write through > /sys/class/scsi_disk/3:0:0:0/cache_type
Là, ça poussait à 90Mo/s avec des blocks de 4k.
Mais j'ai deux problèmes : * Je n'ai pas encore bien compris ce que fait cette commande ni si elle est dangereuse sur un ZIL * Revenir en write back fonctionne mais je ne peux plus revenir en 'temporary write through', même après un reboot.
Ca me bouffe cette histoire.
Julien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/