Lorsque je vérifie les performances des cartes SD pour une écriture aléatoire, je peux voir que les performances sont assez mauvaises pour une taille d'enregistrement de 4 Ko (ce n'est pas surprenant), mais pour plusieurs cartes, elles diminuent même pour des tailles d'enregistrement plus importantes avant d'augmenter. J'ai mesuré les performances d'écriture aléatoire avec iozone v3.430 et testé plusieurs cartes flash de différents fabricants. Il s'agit de la commande iozone, que je mesurais avec une taille de fichier de 50 Mo:
iozone -RaeI -i 0 -i 1 -i 2 -y 4k -q 1M -s 50m -o -f /tmp/testfile
Voici les résultats avec une taille de fichier de 50 Mo:
Question: Quelle est la raison pour laquelle les performances d'écriture aléatoire avec une taille d'enregistrement de 8, 16, 32, 64 et 128 Ko sont plus lentes qu'avec une taille d'enregistrement de 4 Ko?
Peter Brittain a suggéré de tester avec une taille de fichier plus grande, donc je l'ai également essayé avec une taille de fichier de 500 Mo. Voici les résultats:
Les performances globales se sont dégradées mais le phénomène persiste.
Les partitions sont alignées sur des limites de 4 Mo. Le système de fichiers est ext4 avec une taille de bloc de 4 Ko. La partition utilisée pour les tests démarre est mmcblk0p2.
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 953.7M 0 loop /mnt/sdb1
mmcblk0 179:0 0 14.9G 0 disk
├─mmcblk0p1 179:1 0 56M 0 part /boot
├─mmcblk0p2 179:2 0 7.8G 0 part /
└─mmcblk0p3 179:3 0 7G 0 part /mnt/mmcblk0p3
$ cat /etc/fstab | grep mmcblk0p2
/dev/mmcblk0p2 / ext4 defaults,noatime 0 1
$ sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
4 heads, 16 sectors/track, 486192 cylinders, total 31116288 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000981cb
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
/dev/mmcblk0p2 122880 16506879 8192000 83 Linux
/dev/mmcblk0p3 16506880 31115263 7304192 83 Linux
$ mount | grep ext4 | grep root
/dev/root on / type ext4 (rw,noatime,data=ordered)
# tune2fs -l /dev/mmcblk0p2 | grep Block
Block count: 2048000
Block size: 4096
Blocks per group: 32768
Mise à jour 1: il est clair que les performances d'écriture aléatoire, en particulier pour les petites tailles d'enregistrement, sont nettement inférieures par rapport à l'écriture séquentielle. Les cellules de mémoire du stockage flash NAND sont regroupées en pages et appelées blocs d'effacement. Les tailles de page typiques sont de 4, 8 ou 16 Ko. Bien qu'il soit possible pour le contrôleur d'écrire des pages simples, les données ne peuvent pas être écrasées sans être effacées au préalable et un bloc d'effacement est la plus petite unité qu'un stockage flash NAND peut effacer. La taille du bloc d'effacement est généralement comprise entre 128 Ko et 2 Mo. Dans les cartes SD modernes, un petit nombre de blocs d'effacement sont combinés en unités plus grandes de taille égale qui sont appelées groupes d'allocation ou unités d'allocation ou segments. La taille de segment habituelle est de 4 Mo.Chaque opération d'écriture sur le stockage entraîne une opération de lecture-modification-écriture pour un segment entier. Par exemple, sur une carte SD avec une taille de segment de 4 Mo, l'écriture de 4 Ko de données dans des emplacements aléatoires entraîne un facteur d'amplification d'écriture de 1024. Les contrôleurs des cartes SD implémentent une couche de traduction. Pour toute opération d'E / S, une traduction de l'adresse virtuelle en adresse physique est effectuée par le contrôleur. Si les données à l'intérieur d'un segment doivent être écrasées, la couche de traduction remappe l'adresse virtuelle du segment en une autre adresse physique effacée. L'ancien segment physique est marqué comme sale et mis en file d'attente pour un effacement. Plus tard, lorsqu'il est effacé, il peut être réutilisé. Les contrôleurs des cartes SD mettent généralement en cache un ou plusieurs segments pour augmenter les performances des opérations d'écriture aléatoire.Si les cartes SD stockent un système de fichiers racine, il est avantageux que le contrôleur de la carte puisse mettre en cache le ou les segments où se déroulent les opérations d'écriture, les segments, qui stockent les métadonnées du système de fichiers et (si disponible) le journal du système de fichiers. Par conséquent, les performances d'écriture aléatoire d'une carte SD dépendent de la taille du bloc d'effacement, de la taille des segments et du nombre de segments, le cache du contrôleur. Mais tout cela n'explique pas pourquoi les performances d'écriture aléatoire avec une taille d'enregistrement de 8, 16, 32, 64 et 128 Ko sont plus lentes qu'avec une taille d'enregistrement de 4 Ko.
Mise à jour 2 (réponse à myaut): La capture d'écran du tableau est mon propre travail. Actuellement, j'écris un article / article sur les grappes d'ordinateurs à carte unique, car ils sont une option intéressante pour fournir des ressources aux projets étudiants et aux chercheurs. Dans ce contexte, j'ai également étudié les performances du CPU, du stockage et de l'interface réseau d'un seul nœud. J'ai acheté toutes les cartes SD testées. Sur l'une des cartes que j'ai installées (copiées via dd) Raspian Wheezy (version 2014-06-20). Après avoir configuré les paramètres réseau et installé des packages supplémentaires (par exemple iozone), j'ai copié la carte SD entière sur toutes les autres cartes SD.
Mise à jour 3 (réponse à Gabriel Southern): Les résultats proviennent de tests simples. La procédure était:
- Insérez la carte dans le Raspberry Pi modèle B
- Démarrez le système
- Connectez-vous via SSH
- Lancer l'exécution du test iozone
- Arrêtez le système et essayez avec une autre carte SD
Certaines des cartes que j'ai essayé plusieurs fois de vérifier. Il y avait juste peu de variation. Le phénomène se produit tout le temps sauf pour les deux cartes Samsung et une carte Verbatim.
Mise à jour 4: En ce moment j'essaye de trouver un contact avec une entreprise qui produit des contrôleurs flash NAND (Samsung, SanDisk, Toshiba ...) afin d'y demander une réponse définitive. SanDisk a un forum. J'y ai demandé une explication. J'ai également envoyé une demande au service de support technique de Kingston.
Mise à jour 5: la taille du bloc d'effacement et la taille de l'unité d'allocation (segment) ne sont pas responsables du phénomène. Je l' ai testé la taille du bloc d'effacement de toutes les cartes SD avec le pritcsd.py poing d'outil dans le lecteur de carte interne d'un ordinateur portable ThinkPad X240 et enfin avec un modèle Raspberry Pi B. Pour toutes les cartes de la sortie est: Erase block size of mmcblk0 is 65536 bytes. De plus, la taille du segment est identique pour toutes les cartes SD testées. C'est 4 Mo. Ces informations se trouvent dans le fichier /sys/class/mmc_host/mmc0/mmc0*/preferred_erase_size . Il est assez extraordinaire à mon avis que toutes ces cartes ont la même taille de bloc d'effacement et la même taille de segment. Entre-temps, j'ai collecté les ID de produit / numéros d'article dans les emballages des cartes testées. Les voici.
Mise à jour 6: Le support technique de Kingston m'a écrit que les contrôleurs des cartes Kingston testées (et très probablement des autres cartes) sont optimisés pour les fichiers de taille 4 ko. L'implémentation exacte du contrôleur est confidentielle. La réponse de Kingston est la meilleure que j'ai reçue. SanDisk n'a jamais répondu à ma demande d'assistance et je n'ai pas pu trouver de contact de Sony, Samsung ou Verbatim