Pourquoi les performances d'écriture aléatoire de la carte SD pour une taille d'enregistrement de 8 à 128 Ko sont-elles inférieures à celles d'une taille d'enregistrement de 4 Ko?

15

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:

Baisse des performances des cartes SD pour une écriture aléatoire lorsqu'elle est testée avec une iozone et 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:

Baisse des performances des cartes SD pour une écriture aléatoire lorsqu'elle est testée avec une iozone et une taille de fichier de 500 Mo

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:

  1. Insérez la carte dans le Raspberry Pi modèle B
  2. Démarrez le système
  3. Connectez-vous via SSH
  4. Lancer l'exécution du test iozone
  5. 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.

ID de produit / numéros d'article des emballages des cartes testées

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

Pays imaginaire
la source
1
C'est une question intéressante. Les résultats que vous avez rapportés sont-ils des moyennes sur plusieurs séries, ou simplement sur une seule série? Je serais curieux de savoir combien il y a de variation dans les résultats.
1
En raison du remappage logique et du nivellement par usure, cette affirmation à la question "Par exemple, sur une carte SD avec une taille de segment de 4 Mo, l'écriture de 4 Ko de données à des emplacements aléatoires entraîne un facteur d'amplification d'écriture de 1024". c'est faux.
Ben Voigt
1
D'après mon expérience des tests de performances, vous avez atteint toutes sortes d'optimisations et de caches à des tests à plus petite échelle. En particulier, je pouvais croire que les fabricants avec un flash plus lent auraient besoin de ces optimisations pour gérer efficacement les mises à jour du système de fichiers, mais ne peuvent pas le prouver en raison du manque de documentation publique pour tous les contrôleurs. Cela dit, je remarque que vous n'utilisez qu'un fichier de 50 Mo. Avez-vous essayé des fichiers beaucoup plus volumineux (selon les "règles d'exécution" dans iozone.org/docs/IOzone_msword_98.pdf ) pour essayer de contrer cela?
1
En supposant que vous ne voyez aucune différence, j'ai cherché d'autres données à ce sujet. On dirait que Linaro org a fait des recherches similaires . En particulier, le cache SLC extra-large peut expliquer vos résultats très rapides. Et les optimisations FAT32 viseraient spécifiquement les petites écritures.
1
Ouais - déjà repéré ce problème dans la page ... Je pense que vous manquez peut-être quelque chose avec le FAT32: les cartes sont optimisées "pour les modèles d'accès observés sur FAT32" et pas seulement pour FAT32. Un modèle d'accès typique sur FAT sera d'écrire un nouveau fichier - ce qui nécessite que les données du fichier soient diffusées en plus d'une mise à jour FAT. La mise à jour FAT impliquera généralement un petit nombre de blocs. Si j'écrivais un FTL, je prévois donc d'optimiser les écritures plus petites que ma taille de page pour améliorer les performances FAT.

Réponses:

4

Structure des cellules des cartes SD:

En électronique à semi-conducteurs, une cellule est un élément mémoire capable de stocker un ou plusieurs bits d'informations, le nombre de bits par cellule dépendant de la technologie utilisée. (SLC / MLC / TLC)

Les fabricants utilisent différentes technologies dans la mémoire flash pour gérer sa structure, la structure la plus utilisée est TLC et MLC en raison du coût moins élevé lié à ces technologies, en particulier TLC.

Ces informations techniques sont difficiles à obtenir pour les cartes SD et les clés USB, ont décidé les fabricants, en ce qui concerne les autres technologies de type flash, comme les SSD où ces informations sont presque toujours fournies.

Cela a un impact direct sur la durée de vie du matériel mais aussi sur la vitesse.

SLC, cellule à niveau unique (1 bit)

Generally 100000 write erase cycles
Erase time: 1-2.5ms

MLC, cellule à plusieurs niveaux (2 bits ou plus)

Anywhere from 3000 to 15000 write erase cycles
Erase time: 2.5-3.5ms

TLC, cellule à trois niveaux (3 bits)

Anywhere from 1000 to 5000 write/erase cycles
Erase time: 4-5ms

Remarque :

Comme les cellules peuvent contenir 1, 2 ou 3 bits dans certains cas, votre puce de contrôleur de carte SD devra effectuer plus de cycles d'accès en fonction de la taille d'enregistrement et de la capacité de la cellule.

Vos cartes Samsung utilisent probablement une technologie SLC ou elles ont une puce de contrôleur puissante.

Note 2 :

J'ai essayé quelques tests comme vous le faites avec des partitions ext4 taille de bloc 4 ko et 1 ko mais sans grande différence

intika
la source
Les cartes Samsung et la carte Verbatim sont des produits de consommation et ces dernières années, la mémoire SLC n'était pas courante dans de tels appareils. Les cartes Samsung sont MB-MP16D et MB-MS16D et la carte textuelle est le numéro d'article 44007 .
Neverland
Peut-être que les spécifications de certains contrôleurs sont disponibles. Je peux ouvrir les cartes SD et vérifier quels contrôleurs ces cartes contiennent, mais je ne peux pas ouvrir les cartes microSD. Est-il possible de lire l'ID / numéro de produit des contrôleurs de cartes SD via un logiciel?
Neverland