Flaz's Hotline

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Vérifier sa carte SD ======
Sources :
  * [[https://linuxreviews.org/HOWTO_test_SD_cards_and_identify_fake_ones_(mostly_sold_on_ebay)|HOWTO test SD cards and identify fake ones (mostly sold on ebay)]]
  * [[https://handyman.dulare.com/testing-sd-card-capacity-and-speed-in-linux/|Testing SD card capacity and speed – in Linux]]
  * [[https://fight-flash-fraud.readthedocs.io/en/latest/index.html|f3 - Fight Flash Fraud]] (fight-flash-fraud.readthedocs.io)
  * [[https://fight-flash-fraud.readthedocs.io/en/latest/usage.html|f3 Usage]] (fight-flash-fraud.readthedocs.io)

===== Objet =====
Une [[https://fr.wikipedia.org/wiki/Carte_SD|carte SD]](("SD" pour "Secure Digital".)) ou micro-SD n'est pas toujours ce qu'elle prétend être. Entre ce que le marchand (en ligne ou pas) vous a vendu, ce qui est imprimé sur l'emballage ou sur le produit et ce que avez vraiment en main, la différence peut être substantielle.

La plupart du temps, un des indices de suspicion sera un trop belle affaire. Un prix cassé par un marchand inconnu peut être une bonne affaire ou le signe d'une contrefaçon. Les plates-formes marchandes réputées brouillent les pistes puisqu'elles hébergent des marchands peu scrupuleux qui apparaissent et disparaissent au gré des signalements, quand ils sont suivis d'effets. Il est même arrivé que de grandes enseignes physiques se fassent piéger…

Enfin, les cartes SD tendent à devenir de simples //consommables// de haute technologie avec les conséquences négatives que cela entraîne sur les niveaux de contrôle-qualité.
===== Résumé des opérations =====
Pour celles qui connaissent la musique mais qui ont oublié les paroles ;-) Les messages affichés par les commandes sont explicites.
<code>
$ lsblk
$ rm -Rf <mount point>/*
$ f3write  <mount point>
$ f3read <mount point>
$ dd if=/dev/zero of=<mount point>/testfile bs=10MB
# f3probe --destructive --time-ops <device name>
# f3fix --last-sec=<last usable block> <device name>  // <last usable block> = nombre de blocs uitilisables - 1 !!!
# parted -l
</code>

===== Préparatifs =====
Même en l'absence de tout indice, une bonne pratique consiste à contrôler systématiquement toute nouvelle carte SD qui entre en sa possession (achat, don, récupération…). Le but est d'estimer la confiance que l'on peut accorder aux informations imprimées sur la carte, en termes de capacité de stockage et de vitesses d'accès.

Heureusement, l'outil f3(("Fight Flash Fraud", tout simplement !)) a été développé dans ce seul but. Pour l'installer sous Debian :
<code># atp install f3</code>
Il fournit 4 commandes directement utiles à toute simple utilisatrice((Un cinquième outil est destiné aux développeuses.)) : f3probe, f3fix, f3write, f3read.

Les plus simples d'utilisation sont //f3wite// et //f3read// car elles ne demandent aucune connaissance particulière :
insérer la carte SD dans l'ordi((À l'aide d'un lecteur externe de carte SD si nécessaire. Pour les tests de vitesse, être attentives aux limites du lecteur lui-même.))
si elle n'est pas montée automatiquement, la monter manuellement((Dépend de votre système. Faites comme avec une clé USB.)) et repérer le point de montage.

Pour éviter de causer des dommages irréparables à d'autres supports de stockage que celui que l'on veut tester, la commande lsblk affichera l'état des dispositifs de stockage connectés (montés ou non montés) et reconnus par le système.
<code>
lsblk
</code>

On peut alors afficher le contenu de la carte qui devrait être vierge. C'est un premier test.



===== Test de capacité =====
La combinaison de //f3write// et //f3read// va nous permettre de tester la capacité réelle de la carte. <note warning>Cette opération effacera tout ce qui est inscrit sur la carte((Ce qui ne doit pas poser de problème puisqu'elle est censée être vide)).</note>
<code>f3write  point_de_montage</code>
par exemple :
<code>f3write /media/moi/3745-5135/</code>
L'exécution peut être longue((Selon sa capacité et sa vitesse.)) puisque l'objectif est de "gaver" la carte de données jusqu'à ce qu'elle soit pleine. L'écriture s'effectue par blocs de données avec un compte-rendu après chaque écriture. La vitesse d'écriture affichée est une première indication des performances réelles de la carte.
Une fois l'écriture terminée, on procède à une lecture de contrôle de ce qui a été((Ou aurait l'être si la carte est fonctionnelle et n'est pas une contrefaçon.)) écrit, par exemple :
<code>f3read /media/moi/3745-5135/</code>
chaque bloc précédemment écrit est lu et vérifié, avec un compte-rendu après chaque lecture. À la fin, //f3read// affiche la capacité constatée de la carte et les erreurs éventuellement rencontrées.

Les trois types d'erreurs signalés sont les suivants :

  * **changed**: le secteur a été écrit par //f3write//, lu à la position attendue, avec un nombre «acceptable» de modifications (2 inversions de bits, au maximum).
  * **overwritten**: le secteur lu contient des données écrites par //f3write// dans un autre secteur que celui attendu. Il peut également comporter un nombre «acceptable» de modifications. Concrètement, cela signifie que l'information écrite dans un fichier a écrasé l'information écrite dans un autre fichier. Autrement dit, un même secteur physique reçoit les données de 2 secteurs logiques.
  * **corrupted**: le secteur ne contient pas les données écrites par f3write. Cela signifie qu'il y a plus de 2 bits inversés entre les données lues par //f3read// et écrites par //f3write//.

Pour en savoir plus sur l'interprétation des résultats :

  * [[https://fight-flash-fraud.readthedocs.io/en/stable/usage.html#how-to-use-f3write-and-f3read|How to use f3write and f3read]] (en)
  * [[https://unix.stackexchange.com/questions/438449/f3read-what-is-the-difference-between-corrupted-changed-and-overwritten-secto|f3read - what is the difference between corrupted, changed and overwritten sectors?]] (en) (unix.stackexchange.com)

<note tip>Les vitesses de lecture/écriture constatées via //f3read// et //f3write// sont dépendantes du système de fichiers. Elles nous renseignent sur les performances que nous rencontrerons en utilisation réelle. Elles sont nécessairement inférieures aux performances de la carte elle-même, les opérations de lecture/écriture étant ralenties par le système de fichiers et le blocs de lecture-écriture qui ne sont pas optimisés pour faire plaisir aux technologies et paramètres intégrées dans la carte((À la diffférnce des test effectués sur bans de test constructeur.)).</note>
===== Test de vitesse d'écriture =====
==== Continue ====
<note important>Pour ce test, si la clé USB a une capacité supérieur à 4Go, celle-ci ne doit **pas être formatée en FAT32** mais dans un format((Système de fichiers.)) gérant des fichiers de taille supérieure à 4Go (exFat, ntfs, nsf+…).</note>
Une autre commande va nous permettre de conforter l'estimation de la capacité mais surtout de tester la vitesse d'écriture en continu qui est celle généralement mentionnée par le fabricant, sans plus de précision((L'écriture en continu est plus rapide que l'écriture aléatoire. La première intéresse typiquement une caméra numérique. La seconde intéresse un ordi ou smartphone utilisant la carte comme unité de stockage multiusages.)). La forme générale de la commande est la suivante :
<code>dd if=/dev/zero of=point_de_montage/testfile bs=10MB</code>
par exemple,
<code>dd if=/dev/zero of=/media/moi/3745-5135/testfile bs=10MB</code>
En fin d'exécution, la capacité constatée ainsi que la vitesse d'écriture sont affichées.
==== Aléatoire (à explorer) ====
À étudier :
  * [[https://fio.readthedocs.io/en/latest/fio_doc.html|1. fio - Flexible I/O tester rev. 3.30]]
  * [[https://docs.oracle.com/fr-fr/iaas/Content/Block/References/samplefiocommandslinux.htm|Exemples de commande FIO pour les tests de performances de Block Volume sur des instances Linux]]
  * [[http://www.techpository.com/linux-using-fio-for-testing-i-o-performance/| Linux: Using fio for testing I/O performance ]]
  * [[https://linoxide.com/measure-disk-performance-fio/|How to Measure Disk Performance using Fio in Linux]]
  * [[https://www.howtogeek.com/devops/how-to-test-your-unix-servers-disk-and-ram-speed/|How to Test Your Linux Server’s Disk and RAM Speed]]

Dans le cas de la captation d'une vidéo, la vitesse d'écriture en continu rend compte des capacités de la carte dans une situation réelle. Mais lorsqu'elle sert au stockage multiusages, cette vitesse est sans intérêt. L'indice "A" figurant sur certaines cartes est là pour informer sur les capacités d'entrées/sorties aléatoires revendiquées par le fabricant.

Pour mesurer les performances réelles, on dispose de la commande //fio//. Si elle n'est pas déjà installée :
<code># apt install fio</code>
L'utilisation de cette commande est tout sauf intuitive et je n'ai pas eu le temps de l'explorer suffisamment pour la présenter. Cela ne tient pas tant à une syntaxe complexe qu'à la difficulté à laquelle on est confrontée lorsqu'on doit définir clairement ce que l'on entend pas "lecture/écriture aléatoire". Pour ne prendre que deux situations, l'écriture par plusieurs processus dans des journaux d'activité n'a pas grand chose à voir avec l'exécution d'un script de retouche appliqué à un lot d'images en haute définition. Pourtant les deux vont déclencher de nombreux accès sur les supports de stockage. Il faudrait non seulement définir les différentes situations que l'on veut tester mais aussi les pondérer.

Il existe probablement des recueils de recettes //fio// concoctées pour tester des situations d'utilisation déjà été répertoriées (à chercher). Il se pourrait même que quelqu'une ait déjà partagé un script exploitant //fio// pour en sortir des indicateurs synthétiques.

<note warning>Les indications qui suivent dans cette section sont a prendre avec circonspection.</note>

<note tip>Par défaut, la commande //fio// effectue les opérations de lecture/écriture dans le répertoire courant((La commande "pwd" renvoie cette information.)).</note>
Par exemple, la commande suivante serait calibrée pour tester les performances en lecture/écriture d'une clé USB en effectuant un mix de lectures et d'écritures de 4Ko… :
<code>
sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=200M --readwrite=randrw --rwmixread=75
</code>
--- à compléter ---
===== Test de contrefaçon =====
Ce test va tenter d'identifier si la carte a été contrefaite et de cataloguer la technique de contrefaçon utilisée. De plus, il affiche la capacité annoncée par la carte, la capacité réelle constatée et le nombre de "secteurs" contigus utilisables. Cette dernière information peut être utilisée plus tard.

Pour le test, il faut connaître le nom donné au dispositif (//device//) de stockage lui-même et non plus au point de montage qui permet d'en consulter le contenu. La commande suivante affichera une vue des dispositifs identifiés et devrait vous permettre d'y retrouver votre carte SD :
<code>lsblk</code>
Une fois le nom du dispositif noté, on peut lancer la commande, en tant que //root// ou superutilisatrice :
<code># f3probe --destructive --time-ops nom_du_disposotif</code>
par exemple,
<code># f3probe --destructive --time-ops /dev/sdb</code>
Le  nombre de "secteurs" contigus utilisables figure dans la ligne suivante, parmi des résultats affichés :
<code>…
*Usable* size: 7.86 GB (16477879 blocks)
…</code>
ici "16477879".
===== Redimensionnement de la carte =====
Si la capacité réelle de la carte est manifestement inférieure à la capacité indiquée sur la carte((Et que vous ne pouvez pas vous faire rembourser :-()) tout en restant intéressante dans votre cas d'utilisation((Par ex. 64Go au lieu de 128Go…)), il peut être intéressant de corriger l'information erronée enregistrée dans la carte. On le fait en utilisant le dernier secteur utilisable indiqué par //f3probe// :
<code># f3fix --last-sec=16477878 /dev/sdb</code>
<note>0n remarque que la valeur à indiquer dans la commande est exactement la valeur renvoyée par //f3probe// moins 1((Parce que les secteurs sont comptés à partir de 0 au lieu de 1…)).</note>

Il reste conseillé de vérifier l'ensemble des performances de la carte ainsi corrigée.
===== Partitions initiales =====
==== Suppositions ====
Mine de rien, nous avons jusqu'ici supposé que la carte :
  * ne contenait qu'une seule partition
  * que celle-ci était formatée
  * que notre système était capable d'exploiter ce formatage en lecture et écriture.

Il arrive que, sortie de son emballage, la carte contienne une première partition de petite taille (par ex. 16Mo), que le système n'a ni montée automatiquement ni proposé de monter. Certains fabricants de cartes la dédie au contrôleur de mémoire intégré sur la carte :-x. Il est donc conseillé de ne pas y toucher((Sur une carte de plusieurs Go, la perte est négligeable. Quoiqu'on pense de cette pratique, il me semble inutile de prendre des risques.))..
<note>Comment doit-on traiter cette partition si l'on souhaite changer le type de table de partition (MBR vers GPT ou l'inverse.) ? C'est une bonne question à laquelle je n'ai pas la réponse.</note>
==== Le meilleur formatage ? ====
Tout dépend de l'utilisation LOL

Lorsque j'utilise ma carte SD comme un support de stockage interne sur un ordi portable Linux ou un smartphone Android((Ne pas oublier que la carte doit également être lisible par le [[phone:demarrage-chargement-androphone#recovery|recovery]] installé sur l'androphone, par exemple TWRP.)), je choisis //ext4//, sans hésiter, tant pour les fonctionnalités qu'apporte ce //système de fichiers// que pour la technologie des //inodes//, si pratique pour l'enregistrement différentiel.

Si j'utilise ma carte comme un support amovible, je choisis encore //ext4// dans le cas (fréquent) où je la connecte exclusivement à des appareils Linux ou Android. Dans la plupart des autres cas, si //ext4// n'est pas utilisable, je m'aligne sur ce qu'imposent les autres appareils. Mais pas n'importe comment : j'exclus //exFAT//, j'évite //FAT32//, j'utilise //NTFS// si c'est possible. Si je ne connais pas "tous les autres appareils", j'évalue les conséquences d'une limitation de la taille maximale des fichiers à 4Go((Au regard des utilisations prévues et de la capacité totale de la carte.)) et choisis //FAT32// si l'impact est négligeable.

Si cette carte n'est utilisée que dans un seul appareil, je respecte les recommandations du fabricant en partant du principe que le format recommandé est le mieux adapté au firmware. En gros, je fais comme s'il s'agissait d'un composant de stockage interne dont je ne pourrais pas choisir le format.

En savoir plus : [[https://winbuzzer.com/2021/06/30/filesystems-explained-whats-the-difference-between-fat32-ntfs-exfat-hfs-and-ext4-xcxwbt/|Filesystems Explained: What’s the Difference between FAT32, NTFS, exFAT, HFS+, ext4 etc.?]]

=== f2fs ? ===
Le système de fichiers [[https://fr.wikipedia.org/wiki/F2FS|f2fs]] a été conçu pour tirer parti des caractéristiques propres aux équipements de stockage sur semi-conduteurs ([[https://fr.wikipedia.org/wiki/SSD|SSD]]((En anglais : "Solid State Device".))) dont font partie les cartes SD. Les caractéristiques et les performances de f2fs sont séduisantes. C'est probablement le meilleur choix pour une carte SD passant sa vie dans un androphone. On se retrouve alors presque dans le cas d'un composant inamovible où je suggère de suivre la recommandation du fabricant. Des fabricants majeurs de smartphones ont adopté f2fs pour le stockage interne de leur appareils.

J'ai hâte que sa diffusion et son intégration harmonieuse dans le monde GNU-Linux se poursuivent((À ce jour (juillet 2022), il reste du chemin à faire… Il est, par exemple, impossible de donner un nom (label) à une partition //f2fs//, même en utilisant la dernière version de Linux-Mint ! Une fonctionnalité élémentaire pour un support amovible :-D)) afin de reconsidérer sereinement la priorité que je donne à //ext4//. Comparé à ce dernier, //f2fs// n'a pas à rougir de ses performances lorsqu'il accueille le système d'exploitation et les applications. Dans les autres utilisations il distancie //ext4// pouvant même se montrer trois fois plus rapide ! La lecture continue constitue une exception puisque //ext4// s'y montre plus de deux fois meilleur.

En savoir plus :
  * [[https://en.wikipedia.org/wiki/F2FS|F2FS]] (en) (wikipedia)
  * [[https://www.phoronix.com/scan.php?page=article&item=linux-58-filesystems&num=1|XFS / EXT4 / Btrfs / F2FS / NILFS2 Performance On Linux 5.8]]
  * [[https://www.phoronix.com/scan.php?page=article&item=clear-linux-f2fs&num=1|F2FS vs. EXT4 File-System Performance With Intel's Clear Linux]]
  * [[https://unix.stackexchange.com/a/257509|How to change the volume name of a FAT32 filesystem?]]
===== Tests de performances ? =====
==== Performances utiles, disponibles, pures ====

Les performances utiles sont celle qui correspondent à la situation concrète d'utilisation((S'il y en a plusieurs, c'est une mix de ces situations.)). Les performances disponibles sont les maxima mesurés dans des situations type d'utilisation réelle, avec un banc d'essai((En pratique, toute installation dont on s'est préalablement assurée de la fiabilité et des performances qui ne doivent pas entraver les tests parce que trop faibles.)). Les performances pures sont celles obtenue par un dispositifs externe à la carte parvenant à la faire fonctionner aux limites de ses possibilités((Électroniques et logique/performance du contrôleur.)).

Les performances utiles sont nécessairement relatives à une utilisatrice, dans un contexte donné d'utilisation. Elles peuvent être très différentes, pour une même carte. Elle relèvent d'une mesure effective dans le contexte concret et ne peut être réalisée qu'après l'acquisition.
Les performances disponibles donnent une idée, avant acquisition, de ce que pourront être les performances utiles pour soi.

Les performances pures donnent des maxima théoriques. Cela permet de les écarter directement, si elles sont en dessous de nos besoins. Elles sont censées être au moins égales aux performances revendiquées par le fabricant et imprimées sur la carte ou l'emballage. Certains fabricants ont l'honnêteté d'indiquer qu'elles ont été obtenues au moyen de technologies propriétaires. Ce simple fait interdit de les confirmer avec un banc de test, aussi puissant soit-il, qui ne serait pas doté de ces technologies.

Il arrive que les performances pures((Avec un effet domino sur les autres performances.)) d'une carte soit sensiblement supérieures à celles affichées. Cela découle le plus souvent des contrôles qualité qui invalident un produit pour la classe supérieure((Tout en étant au-dessus de la classe inférieure.)) ou de la politique commerciale visant à éviter la défaillance du fabricant sur un type de produit, malgré une insuffisance stock/production. Si des tests effectués par des laboratoires indépendants font état de performances supérieures à celles revendiquées, sur une((Ou même plusieurs !)) carte d'une référence données, elle ne peuvent donc pas être prises pour acquises et encore moins orienter notre choix d'acquisition.

Toutes sont des performances //réelles//. Elle ne décrivent simplement pas la même réalité. Dans le langage courant, on utilisera l'expression "performances réelles" à propos des utiles ou disponibles. C'est vague… L'expression n'est pas à bannir mais il convient alors de préciser de quoi on parle.

==== Une chaîne de mesure ====