SD Card Speed Test : la fondation Raspberry Pi propose son outil officiel

SD Card Speed Test : la fondation Raspberry Pi propose son outil officiel

Utilisable en ligne de commandes

Avatar de l'auteur
David Legrand

Publié dans

Hardware

10/03/2020 5 minutes
9

SD Card Speed Test : la fondation Raspberry Pi propose son outil officiel

Comment savoir si votre carte (micro)SD est suffisante pour être utilisée sur un Raspberry Pi ? La fondation veut aider ses utilisateurs à se faire une idée des performances de leur ordinateur de poche, en commençant par un outil de test destiné aux périphériques de stockage... assez basique.

Depuis quelques mois, on voit le projet Raspberry Pi se renforcer sur un autre aspect que celui du matériel proposé à la vente par la fondation ou le développement de l'OS Raspbian. L'équipe travaille à des outils devant simplifier la vie de ses utilisateurs, comme l'application multiplateforme pour « l'installation » d'une image.

Elle va également sur le terrain de la mesure de performances, pour un élément encore vital des SBC (Single Board Computer) qu'elle propose : le stockage amovible. Dépendant toujours d'une carte (micro)SD, ou d'un périphérique USB dans certains cas, ces ordinateurs compacts peuvent voir leur confort d'utilisation fortement varier.

Pour y voir plus clair, SD Card Speed Test a été créé.

Raspberry Pi et performance du stockage

Malgré les demandes répétées de la communauté, la fondation Raspberry Pi ne propose toujours pas de cartes équipées de puces flash ou même d'une connectique autre qu'un connecteur microSD ou un port USB. 

De fait, cela rend le système très dépendant des performances de ces périphériques de stockage, qui ne sont pas réputés pour être les plus rapides du marché. Peu coûteux, ils affichent dans le meilleur des cas de bons débits en lecture/écriture séquentielle, mais il en est en général tout autrement sur les accès aléatoires et/ou à de petits fichiers.

Si les constructeurs et organismes normalisateurs rivalisent d'ingéniosités pour ce qui est de promettre monts et merveilles à travers différents logos, il n'est pas toujours très simple pour vérifier ce qu'il en est dans la pratique. Certes, il existe sous Linux des outils de mesure de performances, pas toujours simple à prendre en main.

C'est d'autant plus vrai pour l'utilisateur débutant, alors que celui-ci aimerait sans doute savoir simplement si le périphérique de stockage qu'il utilise est rapide ou non, adapté à son besoin. Un critère qui peut évoluer avec le temps, les performances déclinant parfois au fur et à mesure.

Surtout que dans le cas des cartes (micro)SD, certains revendeurs peu scrupuleux, agissant en général via des places de marché de boutiques peu regardantes, mentent sur la réalité des produits qu'ils proposent. Dès lors, comment faire pour s'y retrouver sans avoir à suivre des guides en 15 lignes de commandes ?

Une suite de test clé en main, encore assez pauvre

Les équipes de la fondation ont donc travaillé à une suite de tests en commençant par un outil permettant de relever les performances du périphérique de stockage principal de l'appareil. L'ensemble s'installe assez simplement via APT, présent dans les dépôts de Raspbian. Son code source ne semble pas (encore ?) diffusé sur le dépôt officiel.

sudo apt update && sudo apt install agnostics

Dans la version desktop, il est présent dans le menu Accessoires sous le nom Raspberry Pi Diagnostics et se lance sous la forme d'une interface graphique (Gtk) assez basique. Elle ne propose qu'une possibilité : lancer un test et afficher un résultat binaire permettant de savoir si les performances du stockage principal sont suffisantes ou non.

Raspberry Pi SD Card Speed TestRaspberry Pi SD Card Speed Test
Raspberry Pi Diagnostics ne propose pour le moment qu'un test, mais ça devrait évoluer

Pour ceux voulant aller plus loin, un fichier de log est accessible d'un clic, détaillant les résultats. On voit qu'une analyse est effectuée sur des blocs de 4k et de manière séquentielle. Pour être considérées comme suffisantes, les performances doivent dépasser 10 000 kb/s en écriture séquentielle et 1500/500 IOPS en lecture/écriture aléatoire.

Autant dire que ce n'est pas très exigeant.

Un outil aussi accessible en ligne de commande

Pour ceux qui préfèrent la version Lite de Raspbian, sans interface graphique, l'outil est également accessible via un simple terminal ou un accès SSH. On trouve ses données dans le répertoire suivant :

/usr/share/agnostics

On y trouve un dossier regroupant les éléments de l'interface et le script qu'elle permet de lancer. En réalité, il s'agit d'un simple script bash avec un fichier permettant d'exécuter trois séries de tests via l'outil open source fio. Nous avons placé le code source de ce script par ici pour ceux qui le souhaitent.

Vous pouvez le lancer manuellement de la manière suivante :

. /usr/share/agnostics/sdtest.sh

Le test sera effectué et le résultat s'affichera comme dans la fenêtre de log :

Raspberry Pi SD Card Speed TestRaspberry Pi SD Card Speed Test
Les résultats affichés via l'interface graphique et ceux en ligne de commandes

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Raspberry Pi et performance du stockage

Une suite de test clé en main, encore assez pauvre

Un outil aussi accessible en ligne de commande

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Fermer

Commentaires (9)


ils voudraient pas se concentrer sur le boot USB du Raspberry Pi 4, et nous prévoir du eMMC pour le modèle suivant ? Parce que les SD, franchement, on en a soupé … :craint:



Larsene_IT a dit:





Le sens des priorités :D


hum … je viens de tester sur une buster à jour : 2 écrans de log d’erreur …



next :fumer:


Pour mes RPi, j’ai 2 astuces:



1/ Passer quelques partitions en tmpfs
tmpfs /tmp tmpfs defaults,noatime,nosuid,size=32m 0 0
tmpfs /var/tmp tmpfs defaults,noatime,nosuid,size=32m 0 0
tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=32m 0 0



2/ Utiliser des cartes SD “industrial”. Par exemple:




  • Sandisk I et XI (ex Ref: SDSDQAF3-008G-I)

  • ATP (ex Ref: AF8GUD3A-WAAXX, AF32GUD3-WABXM)



Pour faire simple, ce sont des sortes de mini SSD, c’est du MLC ou TLC, avec un controler qui gère le wear leveling (répartition de l’usure sur les différentes NAND), on peut même récupérer l’état d’usure sur certaines ATP (ok, j’ai pas encore réussi, mais c’est possible :) )



Alors bien sure c’est plus cher qu’une Sandisk 128Go pour téléphone mobile, mais quand on veut faire de la domotique sur un RPi, on veut que ce soit fiable, du coup ce type de carte est clairement intéressant.



Je n’utilise plus que ca dans mes RPi et je n’ai plus aucun problème de SD, alors que j’en ai cramé un nombre incalculable avec des cartes SD classiques, même de marque.


Bonjour tu pourrais préciser la manip pour le point 1?



ForceRouge a dit:


2/ Utiliser des cartes SD “industrial”. Par exemple: Sandisk I et XI (ex Ref: SDSDQAF3-008G-I) ATP (ex Ref: AF8GUD3A-WAAXX, AF32GUD3-WABXM)




Pour ma part j’ai basculé le root sur un SSD relié en USB. La carte SD ne sert qu’au boot (et n’est donc pas sujette à une usure prématurée).
Sans parler des performances qui sont bien meilleures.



Norde a dit:


Pour ma part j’ai basculé le root sur un SSD relié en USB. La carte SD ne sert qu’au boot (et n’est donc pas sujette à une usure prématurée). Sans parler des performances qui sont bien meilleures.




Oui, pareil, là où je peux. Mais d’une part c’est pénible, d’autre part un boot natif USB serait bien mieux, par ailleurs, un support eMMC serait tout de même un minimum, surtout que ça fonctionne bien sur les compute module que j’utilise, enfin pour l’intégration c’est tout de même nul de passer par un support externe non solidaire. c’est moins pratique sur support DIN.



Larsene_IT a dit:


Oui, pareil, là où je peux. Mais d’une part c’est pénible, d’autre part un boot natif USB serait bien mieux, par ailleurs, un support eMMC serait tout de même un minimum, surtout que ça fonctionne bien sur les compute module que j’utilise, enfin pour l’intégration c’est tout de même nul de passer par un support externe non solidaire. c’est moins pratique sur support DIN.




Ah c’est sur que ne c’est pas l’idéal (si au moins le boitier officiel proposait un logement à disque 2,5”…).
Après dès qu’on attaque des projets demandant un stockage sur de données ou la gestion d’une importante Db, le raspberry (eMMC ou pas) n’est pas la solution idéale.



ForceRouge a dit:


Passer quelques partitions en tmpfs : /tmp /var/tmp /var/log




attention au tmpfs, il faut bien comprendre comment ça marche :
tmpsfs un est dossier qui utilise la ram libre en priorité, puis le swap disque : il est perdu au reboot.




  • l’option “size” : n’est pas un espace de RAM réservé, mais la taille maximum avant que l’OS ne puisse plus y écrire, restreindre trop le size va générer des plantages, à l’inverse un size énorme n’a aucun impact autre que consommer du swap en cas d’abus.

  • il faut prévoir du swap : quand un tmpfs déborde il doit déborder en swap, sinon il y’ un risque de plantage. Le swap n’est utile qu’en cas de saturation mémoire pour éviter de planter. /tmp dans un gros tmpfs avec du swap fera moins d’écriture que /tmp sur flash

  • tmpfs ne fonctionne correctment que si tu reboot régulièrement ta machine ou vide de temps en temps ces dossiers un /tmp en tmpsfs sur un PC allumé h24 ne sert à rien.

  • les dossiers /var/ sont censé survivre à un reboot, stocker un dossier /var/xxx en tmpsfs doit être fait avec prudence car l’OS s’attend à retrouver son contenu au reboot.



/tmp doit normalement être par défaut en tmpfs (ou alors il suffit de décommenter la ligne dans /etc/fstab), par contre la taille est bien trop petite tu peux mettre 1 ou 2 go (peu importe la quantité de RAM)
/var/tmp : danger ce dossier sert à stocker de gros fichiers temporaires : un tmpfs pourquoi pas (si t’as du swap pour compenser) tmps à 32M surtout pas !
/var/log : jamais en tmpfs ! Si y’a trop de log tu les désactives ou les limite (log-rotate), les stocker en ram veut dire qu’en cas de plantage tu n’auras pas accès au log (c’est quasi la seule utilité de ces logs)



Pour info sur mon PC /tmp a une size de 8go, /var/portage/tmp 16go (dossier gentoo où sont compilé les appl.) Ma mémoire n’est que de 8go (fortement solliciter en cas de compilations), et j’ai 16go de swap sur HDD qui se tourne les pouces en quasi-permanence.