Comment déterminer la taille du bloc d'effacement Nand du SSD?


14

J'ai récemment acheté un SSD Crucial M500 240 Go (NAND 20 nm) et j'essaie de trouver le meilleur moyen de le partitionner. Actuellement, j'utilise à fdisk -cupartir du secteur 2048.

Je crois que nand page sizec'est 16 Ko.

Je ne trouve nulle part ce que nand erase block sizec'est pour ça.

Quelqu'un connaît-il la réponse à cela ou des conseils généraux sur le partitionnement de cette série particulière de SSD?


1
L'ouverture du lecteur et la recherche sur Google des numéros de pièce sur les puces NAND peuvent être nécessaires.
LawrenceC

Réponses:


7

Ces informations sont parfois publiées dans les spécifications du fabricant SSD, mais d'autres fois, elles ne sont pas là, en particulier pour les cartes mémoire CF ou SD. À moins d'utiliser Google pour rechercher quelqu'un d'autre qui a fait la recherche, vous pouvez essayer de l'estimer vous-même à l'aide de FlashBench. Téléchargez-le ici: https://github.com/bradfa/flashbench

Cet outil effectue des lectures aléatoires sur un SSD et trace un tableau indiquant les temps de lecture. (Vous devriez déjà avoir effectué quelques écritures sur le SSD, car la lecture des pages entièrement effacées est souvent simulée par la puce du contrôleur.) En recherchant des pauses dans le temps par taille de bloc, vous pouvez déduire quelle est la taille du bloc d'effacement. Voici un échantillon du README:

== Devinez effacer les tailles de bloc et de page ==

''flashbench -a <device>''

Il s'agit d'un simple test en lecture seule effectuant de petites lectures au-delà des limites de différentes tailles. Exemple:

$ sudo ./flashbench -a /dev/mmcblk0  --blocksize=1024
align 134217728 pre 735µs       on 1.08ms       post 780µs      diff 324µs
align 67108864  pre 736µs       on 1.05ms       post 763µs      diff 300µs
align 33554432  pre 722µs       on 1.04ms       post 763µs      diff 294µs
align 16777216  pre 727µs       on 1.05ms       post 772µs      diff 302µs
align 8388608   pre 724µs       on 1.04ms       post 768µs      diff 299µs
align 4194304   pre 741µs       on 1.08ms       post 788µs      diff 317µs
align 2097152   pre 745µs       on 950µs        post 811µs      diff 171µs
align 1048576   pre 745µs       on 945µs        post 807µs      diff 169µs
align 524288    pre 743µs       on 936µs        post 799µs      diff 165µs
align 262144    pre 746µs       on 948µs        post 809µs      diff 171µs
align 131072    pre 737µs       on 935µs        post 804µs      diff 165µs
align 65536     pre 735µs       on 925µs        post 796µs      diff 159µs
align 32768     pre 735µs       on 925µs        post 800µs      diff 157µs
align 16384     pre 745µs       on 911µs        post 781µs      diff 148µs
align 8192      pre 785µs       on 808µs        post 725µs      diff 53.3µs
align 4096      pre 784µs       on 788µs        post 779µs      diff 5.85µs
align 2048      pre 787µs       on 793µs        post 789µs      diff 4.65µs

Cela montre les temps d'accès pour effectuer deux lectures de 1024 octets autour des limites des blocs alignés avec une puissance de deux. La lecture à la fin d'une unité de 128 Mo prend environ 735 microsecondes, la lecture du dernier bloc de cette unité avec le premier bloc du suivant prend environ 1080 microsecondes et la lecture des deux premiers blocs d'une unité de 128 Mo prend environ 780 microsecondes.

Le nombre le plus intéressant ici est le dernier, la différence entre le deuxième nombre et la moyenne du premier et du troisième est de 324 microsecondes. Ces chiffres restent tous à peu près les mêmes pour toutes les unités comprises entre 4 Mo et 128 Mo.

Cependant, de 2 Mo à 16 Ko, la dernière colonne a une valeur beaucoup plus faible. Cela indique que tout ce que fait la carte mémoire sur une limite de 4 Mo ne se produit pas aux autres limites. La supposition éclairée ici est que 4 Mo est la taille du bloc d'effacement, également appelée taille du segment ou de l'unité d'allocation. Cette taille de bloc d'effacement devra être utilisée dans d'autres tests après celui-ci.

De même, les limites de 16 Ko et de 8 Ko sont spéciales. L'explication logique est que la carte a des pages de 8 Ko, mais peut utiliser des accès multi-plans pour lire deux pages de 8 Ko simultanément.

Certaines cartes ne montrent qu'un modèle clair en utilisant des accès avec certaines tailles de bloc, d'autres cartes ne montrent aucun modèle, ce qui signifie que les nombres doivent être déterminés différemment.

De plus, les cartes qui n'ont jamais été entièrement écrites peuvent présenter un comportement différent car les temps d'accès sur les segments pré-effacés sont différents de ceux qui ont été écrits.


2

Une autre tentative consiste à aligner sur une frontière qui est une multiplication de n'importe quelle taille de bloc pratique.

Avec ce concept, il est plus courant de s'aligner sur une limite de 1 Mo, donc peu importe si la taille du bloc est de 4 ou 16 ko; tous ces éléments seront multipliés par 2 et en dessous de 1 M, donc l'alignement sur cette frontière les adaptera tous.

Cependant, l'application de ce concept dépend de ce que vous alignez; perdre 1 Mo au début d'un périphérique de stockage de masse est tout à fait acceptable, tout en perdant plusieurs fois dans un scénario différent, ce n'est peut-être pas le cas.


1

La taille du bloc d'effacement n'a aucune incidence sur l'alignement et le M500 prend en charge le ramasse-miettes, les performances ne sont donc pas un problème. Veuillez vous référer à la 2ème page de ce PDF sur le site de micron qui vous aidera à déterminer la taille du bloc d'effacement en fonction de la NAND utilisée dans votre M500.

en ce qui concerne les conseils d'alignement, veuillez consulter ce fantastique post superutilisateur .

Voici la capture d'écran de la page: entrez la description de l'image ici


2
Donc, dans ce cas, où dans ce diagramme la taille du bloc d'effacement serait-elle indiquée?
hbogert
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.