• [^] # Re: mouais

    Posté par (site web personnel) . En réponse au journal Benchmarkez votre clef USB !. Évalué à 5.

    Les cellules flash sont généralements vendues pour 10.000 écritures.

    Pour les clés USB, plutôt 100 000 voire 1 000 000. Bon, peut-être qu'une merdique pas chère sera limitée à dix ou vingt mille.

    Le filesystem FAT est d'usage particulièrement crétin sur ces médias parce qu'à chaque fois que les informations sur les blocs changent, on ré-écrit la FAT et le répertoire, si on travail dans le répertoire racine, l'emplacement est fixe et c'est forcément les mêmes cellules qui sont ré-écrites à chaque fois.

    Heureusement certains (tous ?) contrôleurs de disque USB ne sont pas cons et ne stockent jamais les données au même endroit. À chaque écriture, zou, c'est une autre zone de la clé USB qui est effacée puis écrite.

    Faut dire aussi, les lectures et écritures se font généralement par blocs de 512 octets (le minimum offert au système d'exploitation, qui bien sûr peut utiliser des multiples), mais en pratique la clé est organisée par zones de 64 Ko ou 128 Ko. Tu veux lire ? Pas de problème, le bloc que tu veux. Tu veux mettre des bits à 1 ? Pas de problème, les bits que tu veux. Tu veux mettre des bits à 0 ? Heu, attend un peu, je vide une zone de 128 Ko, et voilà : des bits à 0. Bon en pratique on ne peut pas mettre à 1 ou 0 les bits qu'on veut, vu qu'on écrit un bloc et qu'il y a forcément ou presque des bits qui sont passés à zéro, systématiquement on efface un bloc de 128 Ko pour pouvoir stocker le nouveau bloc dedans.

    Ça veut dire qu'une clé ça ne marche bien qu'avec de l'espace libre. Ça veut dire qu'à chaque écriture, le bloc est ailleurs (la clé gère tout, le système d'exploitation voit bien sûr toujours le même numéro de bloc pour les mêmes données). Ça veut dire qu'il est particulièrement crétin de vouloir défragmenter une clé USB.

    (Note : tout ceci est basé sur la lecture, il y a quelques mois, des specs Intel d'un de leurs contrôleurs de Flash. Y'a peut-être des contrôleurs cons sur le marché aussi.)

    Une logique embarquée dans la clef dispose d'un petit pool de mémoire non mappé qui permet de ré-affecter les blocs morts, ça permet de doubler ou tripler la durée de vie et évite de mettre la clef à la poubelle lorsque les cellules contenant la FAT sont mortes.

    Tu décris les secteurs de secours d'un disque dur, là ? (Ou alors certains contrôleurs cons hypotétiquement sur le marché.)

    e fait de monter la clef en sync doit produire un paquets d'écriture, je n'ai pas analysé le script. Créer et effacer le fichier dans le répertoire racine génère au moins deux écritures. D'après les logs, le bench provoque au moins 13 créations de fichiers, et autant de destruction, soit 26 écritures du répertoire racine. Quand on le lance 4 fois, on a déjà 'consommé' au minimum 1% de la durée de vie de la cellule concernée.

    À chaque fois que tu accèdes à un fichier, son atime est modifié. Ça fait pas mal d'écritures ça, surtout que beaucoup de gens créent leurs fichiers directement dans la racine. Donc, celle-ci devrait mourir en un an ou deux. Donc, c'est forcément arrivé à quelqu'un ici. Pourquoi personne n'en parle ? Parce que les secteurs ont une durée de vie nettement plus longue, ou parce qu'ils ne sont jamais stockés au même endroit ?