Effectivement, faire un test de performance disque en utilisant les données issues de /dev/urandom (ou pire de /dev/random) n'est pas vraiment pertinent en raison de la vitesse de génération de ces données pseudo-aléatoires.
D'un autre côté, utiliser /dev/zero ne me semble pas pertinent non plus, puisque c'est la même donnée qui se répète dans tous le fichier.
Un voie possible pourrait être d'utiliser /dev/urandom pour créer un gros fichier sur un système de fichiers en RAM (/dev/shm par exemple) et de prendre ce fichier comme source pour l'écriture sur le disque à tester. Mais même dans ce cas, le résultat peut être biaisé en raison des optimisations faites par l'OS (cache en lecture, même si avec un fichier en RAM ça ne doit pas jouer, et bufferisation des écritures [je ne sais pas comment dd gère cela]).
Sinon, il existe aussi la commande hdparm qui, avec l'option «-t», permet de se faire une idée des performances en lecture du disque.
[^] # Re: /dev/urandom
Posté par JJD . En réponse au journal HOW TO : Bench this SSD. Évalué à 3.
Effectivement, faire un test de performance disque en utilisant les données issues de /dev/urandom (ou pire de /dev/random) n'est pas vraiment pertinent en raison de la vitesse de génération de ces données pseudo-aléatoires.
D'un autre côté, utiliser /dev/zero ne me semble pas pertinent non plus, puisque c'est la même donnée qui se répète dans tous le fichier.
Un voie possible pourrait être d'utiliser /dev/urandom pour créer un gros fichier sur un système de fichiers en RAM (/dev/shm par exemple) et de prendre ce fichier comme source pour l'écriture sur le disque à tester. Mais même dans ce cas, le résultat peut être biaisé en raison des optimisations faites par l'OS (cache en lecture, même si avec un fichier en RAM ça ne doit pas jouer, et bufferisation des écritures [je ne sais pas comment dd gère cela]).
Sinon, il existe aussi la commande hdparm qui, avec l'option «-t», permet de se faire une idée des performances en lecture du disque.