Journal Benchmarkez votre clef USB !

Posté par  (site Web personnel) .
Étiquettes : aucune
0
1
nov.
2004
Voici un petit script pour tester la vitesse d'écriture sur votre clef USB.
http://ccomb.free.fr/usb-storage-benchmark.sh(...)

1) Branchez votre clef USB
2) Assurez-vous qu'elle n'est pas montée, ou démontez-la.
3) téléchargez le script : wget http://ccomb.free.fr/usb-storage-benchmark.sh(...)
4) rendez-le exécutable : chmod a+x usb-storage-benchmark.sh
5) devenez root : su
6) lancez le script ./usb-storage-benchmark.sh
7) Entrez le périphérique de la partition de test (par défaut : /dev/sda1)
8) Venez publier votre résultat ici. (en précisant votre distro)

Il n'y a normalement aucun risque pour les données présentes sur la clef USB. Le script se contente de copier un fichier plusieurs fois de différentes façons.

Pour info, voici mon résultat :
(Intelligent Stick USB1 en FAT16)
# ./usb-storage-benchmark.sh
USB key device= [/dev/sda1] ?
Testing write speed with a 656kB file...
blocksize=512 ... 9 kB/s
blocksize=1024 ... 17 kB/s
blocksize=2048 ... 35 kB/s
blocksize=4096 ... 62 kB/s
blocksize=8192 ... 114 kB/s
blocksize=16384 ... 204 kB/s
blocksize=32768 ... 265 kB/s
blocksize=65536 ... 350 kB/s
blocksize=131072 ... 332 kB/s
blocksize=262144 ... 362 kB/s
blocksize=524288 ... 348 kB/s
blocksize=1048576 ... 383 kB/s
normal copy operation with 'cp'... 35 kB/s

J'ai fait ça pour mettre en évidence un problème de choix du blocksize pour les opérations sur les clefs USB formattées en FAT (16 ou 32).

À moins que je ne sois le seul à connaitre un taux de transfert de 35ko/s ?

Toute suggestion est la bienvenue sur cette page de wiki : http://ccomb.free.fr/wiki/wakka.php?wiki=UsbStorageBenchmark(...)
  • # 404

    Posté par  (site Web personnel) . Évalué à 3.

    pour l'instant, j'ai un 404 sur ton lien :(
    • [^] # Re: 404

      Posté par  (site Web personnel) . Évalué à 3.

      Zut, je suis trop con. Le script n'était pas au bon endroit. Ca devrait être bon maintenant.
    • [^] # Re: 404

      Posté par  (site Web personnel) . Évalué à 4.

      Normal, c'est pour faire de la pub pour sa page web lol

      Plus sérieusement, je trouve ces résultats étranges et j'aimerais bien voir le source: en principe sur une clef USB le temps d'accès est constant. Donc en supposant négligeable le temps de lecture de la FAT devant la taille du fichier (ce qui ne me parrait pas trop risqué -_^), le fait d'exiger des blocs continus ou non (suivant le blocksize) devrait pas changer grand chose...

      Par ailleurs, si il fait bien un dd dans un fichier, comme je crois le comprendre à partir des deux-trois informations qu'il a laissé filtrer, alors le résultat n'a rien à voir avec le blocksize de la FAT et vient simplement de la gestion du cache par le noyeau.

      Mais ça partait probablement d'une bonne intention ^_^.
      • [^] # Re: 404

        Posté par  (site Web personnel) . Évalué à 4.

        ... J'ai lu le code et il m'a l'air bon.

        Donc ce résultat surprenant doit plutôt avoir quelque chose à voir avec le temps de latence de l'USB, qui il devrait lui aussi devenir négligeable quand on transfert de "gros" blocs, autrement dit, avec un cache.
        Ce qui fait que je persiste à penser que le blocksize ne devrait pas avoir d'influence en temps normal (avec le cache activé).
        Quelqu'un pour confirmer (cp /bin/bash sur sa clef, syncer et mesurer le temps)? (et si, après tout cela, le blocksize avait finalement bien une influence, il faudrait réellement penser à rajouter un cache au pilote des disques USBs)
        • [^] # Re: 404

          Posté par  . Évalué à -1.

          " ... J'ai lu le code et il m'a l'air bon."

          Dois-je comprendre que tu as lu le code APRES l'avoir executé?
          Je suis certainement Parano, mais bon ...
  • # "656kB file"

    Posté par  . Évalué à 1.

    Salut!

    Cela me parrait bien interessant comme sondage, mais penses-tu que ce soit un test vraiment légitime si le fichier fait seulement 656kB, alors que tu atteins des taux de transfert dans les 350kB/s?

    On peut p-e changer?
    Sauf que, oui, pour moi aussi, pour le moment, c'est 404...

    Nico.
  • # mouais

    Posté par  (site Web personnel) . Évalué à 0.

    benchmark sur quoi ? tu parles de ces systèmes amovibles dont le nombre d'écritures est limité ?

    Ben oui, sur ces mémoires flash le nombre d'écriture est limité. C'est assez grand et assez bien foutu pour ne pas être un problème, mais il ne me viendrait pas à l'esprit de faire des écritures inutiles volontairement uniquement pour pouvoir dire que j'ai la plus grosse (euh, la plus rapide)
    • [^] # Re: mouais

      Posté par  (site Web personnel) . Évalué à 3.

      Il ne s'agit pas d'avoir la plus grosse. Pour l'instant c'est même le contraire : je suis à 35ko/s, c'est à dire en gros la vitesse d'une disquette.

      Quand on sait qu'avec l'USB1 ça devrait plutôt approcher le Mo/s (et plus pour l'USB2), je me dis qu'il y a un gros pb quelque part.

      Alors je cherche à savoir si tout le monde est limité par son blocksize, ou bien si le probleme n'existe que pour quelques distros, ou quelques clefs.
    • [^] # Re: mouais

      Posté par  . Évalué à 6.

      Entre 100 000 et 1 million d'écritures. Il y a un autre objet qui peut servir entre 100 000 et 1 million de fois: un interrupteur. Et qui n'a jamais joué à faire stroboscope?
      • [^] # Re: mouais

        Posté par  . Évalué à 6.

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

        * 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.

        * 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.

        Le 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.
        • [^] # Re: mouais

          Posté par  (site Web personnel) . Évalué à 3.

          Et alors ? Une fois qu'elle est usée, on la change...
          Le but ici n'est pas de l'user pour rien, mais de trouver un bug des distribs ou du noyau qui fait que les écritures sont entre 10 et 20 fois plus lentes que ce qu'elles devraient être.
        • [^] # Re: mouais

          Posté par  . Évalué à 5.

          * Les cellules flash sont généralements vendues pour 10.000 écritures.
          Les cellules flash sont plutot vendues pour 100 000 à 1 million de cycles d'écriture. De plus avec les techniques de "repartition d'usure"(wear leveling) embarquées dans les clefs, cela augmente encore le nombre de cycles. Bref le script provoque plutot une usure de l'ordre de 0.005% dans le pire des cas. Pour donner un ordre d'idée on peut lancer le script 10 fois par jour pendant 5 ans avant que les premières cellules ne commencent à ne plus vouloir s'effacer! ;o)
        • [^] # Re: mouais

          Posté par  . Évalué à 2.

          Pour éviter le viellissement prématuré de ma clef USB je l'ai formaté en ext2 et je la monte avec l'option noatime. J'ai bon ?
          • [^] # Re: mouais

            Posté par  . Évalué à 2.

            Pour le noatime oui, pour le formatage ext2 non. Le FS va passer son temps à réorganiser les fichiers en fonction du nombre de fois ou tu y accèdes.
            • [^] # Re: mouais

              Posté par  . Évalué à 2.

              Pour le noatime oui, pour le formatage ext2 non. Le FS va passer son temps à réorganiser les fichiers en fonction du nombre de fois ou tu y accèdes.

              Tu m'étonnes beaucoup, pourquoi le FS s'amuserait à bouger les fichiers accédés en lecture ? As-tu un URL ou un bout de code qui peut confirmer tes dires ?
          • [^] # Re: mouais

            Posté par  . Évalué à 3.

            jffs2, c'est plus fait pour.
            • [^] # Re: mouais

              Posté par  . Évalué à 3.

              J'ai jeté un coup d'oeil sur jffsm j'ai l'impression que c'est fait pour des systèmes flash embarqués, est-ce que ça vaut le coup sur une clef USB "toute bête" ? Est-ce qu'on a la même facilité d'utilisation qu'avec les autres fs ? Et sinon, la question ultime, quel est *le* fs de la mort qui tue à utiliser sur une clef USB pour économiser au max la clef, avoir les meilleures perfs, perdre le minimum de place, avoir un café tout prêt le matin, les gosses qui obéissent, etc...
              • [^] # Re: mouais

                Posté par  . Évalué à 2.

                En effet les systemes de fichier de gestion de flash comme jffs, jffs2 sont utilisés pour gérer l'accès direct à une flash. Dans le cas des clef usb (ou meme des compact flash), la flash est masquée par un controleur, et ces systemes de fichiers perdent tout leur interet.
          • [^] # Re: mouais

            Posté par  (site Web personnel) . Évalué à 2.

            ext2 ne fait pas une écriture lors du démontage ? je crois bien (la question s'était surtout posée pour la question des CDs/DVD à utiliser comme disque dur)
            • [^] # Re: mouais

              Posté par  . Évalué à 2.

              ext2 ne fait pas une écriture lors du démontage ?

              En effet, ext2/3 effectue une écriture au démontage, pour marquer le filesystem "clean". C'est ce qui permet au système de détecter un manque de démontage, par ex en cas de crash (... has not been unmounted properly, checking filesystem ou assimilé).
              On peut voir l'état "clean" ou pas avec un "dumpe2fs" sur le périphérique.
        • [^] # Re: mouais

          Posté par  (site Web personnel) . É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 ?
      • [^] # Re: mouais

        Posté par  (site Web personnel) . Évalué à 4.

        moi ma maman me disait toujours "arrêtes, tu vas claquer l'ampoule avec tes bêtises". Et bon, une clé USB si ce n'est plus extrêmement cher, c'est tout de même pas gratuit. Enfin vous faites ce que vous le voulez mais je préférais le signaler pour ceux qui n'avaient pas pensé que ça réduisait inutilement la durée de vie de leur clé.
  • # cache

    Posté par  . Évalué à 3.

    moi j'aimerais bien voir ton script parce que j'aimerais savoir comment tu gères les phénomène de cache. pour faire un bench exaustif j'aurais fait

    pour block_size dans (512, ..., 65536) faire
    mesurer le temps de :
    mount /usb
    dd ....
    umount /usb
    fin mesure
    fin pour
  • # Résultats

    Posté par  . Évalué à 2.

    # ./usb-storage-benchmark.sh
    FATAL: Module vfat not found.
    USB key device= [/dev/sda1] ?
    Testing write speed with a 653kB file...
    blocksize=512 ... 450 kB/s
    blocksize=1024 ... 768 kB/s
    blocksize=2048 ... 1332 kB/s
    blocksize=4096 ... 1978 kB/s
    blocksize=8192 ... 2720 kB/s
    blocksize=16384 ... 3109 kB/s
    blocksize=32768 ... 3627 kB/s
    blocksize=65536 ... 3841 kB/s
    blocksize=131072 ... 3627 kB/s
    blocksize=262144 ... 3841 kB/s
    blocksize=524288 ... 3627 kB/s
    blocksize=1048576 ... 3627 kB/s
    normal copy operation with 'cp'... 1332 kB/s


    Clef USB 2.0 de marque PQI, 128 Mo, acheté 34 euros.
    • [^] # Re: Résultats

      Posté par  (site Web personnel) . Évalué à 1.

      Ok, tes résultats confirment les miens :

      Ta clef peut monter à 3.6 Mo/s, mais elle reste bloquée à 1.3Mo/s.
      J'avais remarqué que le probleme apparait avec la commande 'cp' mais aussi en faisant une copie de fichier depuis nautilus. Par contre konqueror semble choisir lui-même le blocksize et permet de faire des copies à vitesse maximale.
    • [^] # Re: Résultats

      Posté par  . Évalué à -2.

      Mince, j'ai oublié ma distribution: Debian Unstable, noyau 2.6.7, support USB 2.0 en module.

      J'en profite pour mettre les références totales de ma machine:
      - CM Gigabyte GA-7VT600L
      - AMD 2200+
      - 512 MO DDR Kingston
      - GForce 4 MX 440 AGP 8x
      - DD IBM 60 GXP

      Les lecteurs optiques et SCSI, inutile je pense.
    • [^] # Re: Résultats

      Posté par  . Évalué à 1.

      j'ai aussi une clé USB 2.0 de PQI et les résultats sont qlq peu différents:

      # ./usb-storage-benchmark.sh
      USB key device= [/dev/sda1] ? /dev/sda
      Testing write speed with a 596kB file...
      blocksize=512 ... 903 kB/s
      blocksize=1024 ... 1528 kB/s
      blocksize=2048 ... 2128 kB/s
      blocksize=4096 ... 2838 kB/s
      blocksize=8192 ... 2980 kB/s
      blocksize=16384 ... 3725 kB/s
      blocksize=32768 ... 3311 kB/s
      blocksize=65536 ... 3505 kB/s
      blocksize=131072 ... 3725 kB/s
      blocksize=262144 ... 3973 kB/s
      blocksize=524288 ... 5418 kB/s
      blocksize=1048576 ... 5418 kB/s
      normal copy operation with 'cp'... 1568 kB/s

      sous Ubuntu Warty, kernel 2.6.8 , carte mère Asus a7v8x , cpu AMD athlon XP 2000+
      • [^] # Re: Résultats

        Posté par  (site Web personnel) . Évalué à 2.

        Dans ton cas, le meilleur ioblocksize n'est pas 65ko, mais 512ko.

        Bon, tout ça prouve bien une chose : le mode "sync" n'est pas du tout adapté aux clefs usb, alors que ce serait le type de périphérique pour lequel ce serait le plus pratique. (Débranchement intempestifs)

        Il faudrait une option de montage qui permette de dire au noyau de prendre un ioblocksize égal à la taille du fichier à transmettre. Ou bien qu'il le fasse tout seul.
        Ou bien qu'il commence par sa valeur par défaut puis qu'il augmente tout seul le ioblocksize pour trouver l'optimal.
  • # bouarf ...

    Posté par  (site Web personnel) . Évalué à 1.

    Sur Debian Sid, kernel 2.6.7, les ports sont de l'usb 1 (ou 1.1)

    1ere clé usb de 64Mo de marque heu ... WonQ (c'est coréen je crois) enfin c'est de la memoire Samsung à l'intérieur

    Testing write speed with a 656kB file...
    blocksize=512 ... 10 kB/s
    blocksize=1024 ... 17 kB/s
    blocksize=2048 ... 36 kB/s
    blocksize=4096 ... 71 kB/s
    blocksize=8192 ... 100 kB/s
    blocksize=16384 ... 274 kB/s
    blocksize=32768 ... 410 kB/s
    blocksize=65536 ... 529 kB/s
    blocksize=131072 ... 529 kB/s
    blocksize=262144 ... 516 kB/s
    blocksize=524288 ... 533 kB/s
    blocksize=1048576 ... 529 kB/s
    normal copy operation with 'cp'... 9 kB/s

    Pas génial quoi ...

    2e clé usb de 128Mo de marque PNY
    Testing write speed with a 656kB file...
    blocksize=512 ... 165 kB/s
    blocksize=1024 ... 281 kB/s
    blocksize=2048 ... 388 kB/s
    blocksize=4096 ... 415 kB/s
    blocksize=8192 ... 533 kB/s
    blocksize=16384 ... 624 kB/s
    blocksize=32768 ... 546 kB/s
    blocksize=65536 ... 662 kB/s
    blocksize=131072 ... 662 kB/s
    blocksize=262144 ... 461 kB/s
    blocksize=524288 ... 662 kB/s
    blocksize=1048576 ... 662 kB/s
    normal copy operation with 'cp'... 260 kB/s

    Les 2 sont en fat32, doit quand meme y avoir un leger probleme avec la 1ere.
    • [^] # Re: bouarf ...

      Posté par  (site Web personnel) . Évalué à 3.

      Donc je ne suis pas un cas isolé !

      9ko/s au lieu de 530ko/s pour la 1ere,
      260ko/s au lieu de 662ko/s pour la 2eme.

      -----------------

      Et sinon, je viens d'essayer avec un jukebox6000, qui a deux partitions :
      la 1ere en FAT (32 je crois) :
      blocksize=65536 ... 656 kB/s
      normal copy operation with 'cp'... 485 kB/s

      485 ko/s au lieu de 650 ko/s

      Et la 2eme est en ext2, c'est encore pire :
      # ./usb-storage-benchmark.sh
      USB key device= [/dev/sda1] ? /dev/sda2
      Testing write speed with a 656kB file...
      blocksize=524288 ... 546 kB/s
      normal copy operation with 'cp'... 141 kB/s

      141ko/s au lieu de 546ko/s !
      • [^] # Re: bouarf ...

        Posté par  . Évalué à 2.

        Et si tu allais voir les source de 'cp' ?
        Ptet que ca copie par block de 1 ko, je sais pas moi :p
  • # pour info

    Posté par  . Évalué à 3.

    y a quelqu'un qui a essayer de faire le bench avec le driver ub present dans le 2.6.9 .
    Logiquement les perf devrait etre moins bonne qu'avec le usb_storage, mais on ne sais jamais...
  • # hdparm(8) ?

    Posté par  (site Web personnel) . Évalué à 3.

    Heu hdparm -t fait pas la même chose par hasard ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: hdparm(8) ?

      Posté par  (site Web personnel) . Évalué à 4.

      hdparm fait aussi des tests (de lecture), mais le but n'était pas d'afficher les taux de transferts tous seuls, mais de faire la comparaison entre le blocksize par défaut utilisé par cp et le blocksize optimal qui semble être 65536.

      Et la différence est grosse.
      Ca vaut bien un rapport de bogue dans toutes les distribs.

      Avec des trucs comme ça, on se récupère des commentaires du style « windows c'est plus rapide pour les clefs USB"...
  • # blksize

    Posté par  (site Web personnel) . Évalué à 5.

    Après avoir regardé les sources de cp,
    j'ai constaté qu'il détermine le blocksize en faisant un simple 'fstat'.
    Dans coreutils:src/copy.c:278 :
    /* Determine the optimal buffer size. */
    if (fstat (dest_desc, &sb))
    (...)


    Et effectivement ça concorde :

    # stat /media/IntelligentStick/
    File: `/media/IntelligentStick/'
    Size: 16384 Blocks: 32 IO Block: 2048 répertoire

    Le IO Block vaut 2048.
    L'idéal serait plutôt 65536

    Reste à savoir d'où vient ce 2048.
    • [^] # Re: blksize

      Posté par  (site Web personnel) . Évalué à 4.

      Avec ça : strace -v stat -c "%o" /media/IntelligentStick/

      On obtient :
      (...)
      lstat64("/media/IntelligentStick/", {st_dev=makedev(8, 1), st_ino=1, st_mode=S_IFDIR|0744, st_nlink=9, st_uid=0, st_gid=0, st_blksize=2048, st_blocks=32, st_size=16384, st_atime=2004/11/02-01:37:23, st_mtime=2004/11/02-01:37:23, st_ctime=2004/11/02-01:37:23}) = 0
      (...)

      Ce qui veut dire que le 2048 provient directement d'un appel système. Le problème vient donc probablement soit du noyau, soit du programme qui a décidé en amont (mkdosfs ? mount ?)
      • [^] # Re: blksize

        Posté par  (site Web personnel) . Évalué à 2.

        Marrant. D'apres man mount chez moi:
        Mount options for fat
        blocksize=512 / blocksize=1024 / blocksize=2048
        Set blocksize (default 512).


        Je teste des que je retrouve une clé usb... :)
        • [^] # Re: blksize

          Posté par  (site Web personnel) . Évalué à 1.

          Y'a des gens qui se compliquent la vie...
          mkfs.vfat -S logical-sector-size /dev/sda1
          • [^] # Re: blksize

            Posté par  (site Web personnel) . Évalué à 3.

            Y'a des gens qui confondent les Logical Sectors (la taille des secteurs sur le disque) avec les IO Blocks (la taille des blocks transférés vers le disque)...
            • [^] # Re: blksize

              Posté par  (site Web personnel) . Évalué à 2.

              Non, je suppose simplement que Linux transfert les secteurs logique en un seul burst (même si j'ai la flegme d'aller vérifier -_^).
              Ça a été confirmé par un gars un peu plus loin, sauf erreur.
        • [^] # Re: blksize

          Posté par  (site Web personnel) . Évalué à 2.

          Ca ce serait l'idéal, mais ça ne marche pas.
  • # cache

    Posté par  (site Web personnel) . Évalué à 3.

    Qu'est-ce que fait "mount -o sync" ? Il effectue les écritures au plus tôt. Ça annihile donc toute tentative de cache. Les écritures sont faites par bloc écrit et le noyau attend que le périphérique ait fini son écriture pour continuer. Dans le cas d'un périphérique lent ça ruine les performances. Je suis même pas sûr qu'après un umount il n'y a pas des écritures toujours en cache (pas encore sur disque). Peut-être voir avec "sync". Sûrement lire les sources de hdparm serait utile.

    En utilisation, essaie de tester sans désactiver le cache (sans "-o sync") et cp devrait alors bien mieux s'en tirer. Je pense que si on veut des performances avec une clé il ne faut pas utiliser "-o sync". C'est utile principalement pour le neuneu qui risque d'enlever sa clé sans avoir démonté les périphériques.
    • [^] # Re: cache

      Posté par  (site Web personnel) . Évalué à 3.

      Je suis même pas sûr qu'après un umount il n'y a pas des écritures toujours en cache

      Euh, là ce serait vraiment grave ...

      En utilisation, essaie de tester sans désactiver le cache (sans "-o sync") et cp devrait alors bien mieux s'en tirer.

      oui, effectivement :

      voir : http://ccomb.free.fr/usb-storage-benchmark-async.sh(...)
      # ./usb-storage-benchmark-async.sh
      USB key device= [/dev/sda1] ?
      Testing write speed with a 656kB file...
      blocksize=512 ... 334 kB/s
      (...)
      blocksize=1048576 ... 332 kB/s
      normal copy operation with 'cp'... 312 kB/s


      est utile principalement pour le neuneu qui risque d'enlever sa clé sans avoir démonté les périphériques

      Malheureusement, ceux que tu appelles les neuneu sont nombreux, et les gens sont (on connait le refrain) habitués au comportement de windows. Pour un périphérique non-amovible, le cache est bien pratique, mais pour ceux qui peuvent être retiré de force, l'option "sync" est une bonne chose :
      je pense que tu n'est pas non plus à l'abris d'un « neuneu » qui arrive derrière toi et qui débranche ta clef USB sans te demander si tu l'a démontée.

      Or, il est possible d'obtenir le taux de tranfert maximum, même avec l'option sync : il suffit de choisir le bon IO Blocksize. Ce que je cherche à savoir est donc comment est déterminé ce maudit IO Blocksize.
      • [^] # Re: cache

        Posté par  (site Web personnel) . Évalué à 2.

            Je suis même pas sûr qu'après un umount il n'y a pas des écritures toujours en cache

        Euh, là ce serait vraiment grave ...


        Pourquoi ? Le noyau te garantit une cohérence entre des tâches ordonnées. Il n'y a pas de raison pour flusher les buffers au démontage d'une partition. D'autant plus que les périphériques amovibles sont loin d'être les seuls au monde :). Sauf si tu me trouves dans SUS ou POSIX qu'il faut flusher au démontage d'une partition ? J'ai même trouvé dans des archives de la LKML que certains affirmaient que ce n'était pas effectuė.

        Perso avant d'enlever une clé USB je démonte la partition, j'invoque sync deux fois, et j'enlève le module usb-storage, ce dernier ayant la manie d'être foireux quel que soit la version du noyau utilisée.

        Malheureusement, ceux que tu appelles les neuneu sont nombreux,

        Certes. Et quand je dis "neuneu" c'est pas forcément aussi insultant que dans la bouche d'autres. Mes parents sont des neuneus de l'ordinateur.

        Je pense cependant que cp n'a pas à être configuré spécialement pour les périphériques lents amovibles utilisés par des neuneus.

        Il serait intéressant de tester avec supermount aussi tiens. Ça doit être plus ou moins équivalent à un mount -o sync mais il est possible qu'ils aient mis un délai sur le démontage automatique du FS utilisé, même quelque chose comme 1 seconde sans opération et on serait dans des performances avec cache sans que le neuneu y perde quoi que ce soit.

        Enfin au sujet du IO blocksize, en raisonnant par l'absurde on pourrait se demander pourquoi il n'est pas toujours maximal. Quels sont les problèmes potentiels à l'utilisation d'un très gros blocksize inconditionnellement ?
        • [^] # Re: cache

          Posté par  . Évalué à 2.

          > Enfin au sujet du IO blocksize, en raisonnant par l'absurde on
          > pourrait se demander pourquoi il n'est pas toujours maximal. Quels
          > sont les problèmes potentiels à l'utilisation d'un très gros blocksize
          > inconditionnellement ?

          Plus tu augmentes ce cache, plus tu perds de données en cas de problème/débranchement violent/reboot.
        • [^] # Re: cache

          Posté par  (site Web personnel) . Évalué à 2.

          J'ai l'impression qu'il calcule le ioblocksize en fonction de la partition.
          Quand je formatte en FAT32, j'obtiens, 512
          en FAT16 2048, et en FAT12 (oui en FAT12 !:) 32768

          Mais si je force le ioblocksize à 65536 avec dd sur une FAT12, je monte à un taux de 450ko/s ce qui est le maximum que j'ai vu avec mon i-stick.
        • [^] # Re: cache

          Posté par  . Évalué à 5.

          Il n'y a pas de raison pour flusher les buffers au démontage d'une partition.

          Tu plaisantes je suppose !
          Evidemment qu'il faut flusher les buffers avant de démonter une partition, sinon à quoi bon l'avoir montée pour écrire dedans ?

          Perso avant d'enlever une clé USB je démonte la partition, j'invoque sync deux fois,

          Ton sync ne sert à rien s'il est effectué après le démontage (vu que le démontage provoque l'écriture des buffers "sales" sur le périphérique). Une partition une fois démontée, il n'y a plus de lien logique dans le noyau entre le périphérique bloc (par ex /dev/sda1) et le point de montage (par ex /mnt/sda1).

          Pour en revenir au sujet initial sur la vitesse de transfert vers la clef USB, dans mon cas j'obtiens à peu près la même vitesse avec "cp" que la vitesse théorique maximale (dans les 700-800 Ko/s pour de l'USB1, mais je ne suis pas devant pour vérifier). Je suis à peu près certain que la clef n'est pas montée en mode "SYNC". L'avantage est que l'écriture est plus rapide du point de vue de l'utilisateur, et également que la bufferisation doit provoquer moins d'écritures sur la clef (amélioration de la durée de vie). Comme l'a souligné un autre commentaire, l'inconvénient du mode sync est que si on a copié un gros paquet de données, si on est ensuite pressé de partir avec la clef, le démontage prend du temps à cause de l'écriture effective sur la clef (flush du buffer cache).
          N'étant pas un débutant je préfère monter ma clef en mode normal (asynchrone, avec bufferisation du noyau).

          A noter aussi que la vitesse de lecture ou d'écriture sur une clef USB dépend du contrôleur mémoire qui est dessus. J'avais vu un test et il y avait 2 types de contrôleurs apparemment, avec une différence d'environ 100 Ko/s pour de l'USB1. Sur ma clef 256 Mo USB2, j'ai déjà atteint plus de 5 Mo/s sur un PC de bureau avec USB2, mais là on est limité par les chips mémoire.
          • [^] # Re: cache

            Posté par  (site Web personnel) . Évalué à 1.

            Evidemment qu'il faut flusher les buffers avant de démonter une partition, sinon à quoi bon l'avoir montée pour écrire dedans ?

            Lis le reste de mon argumentaire et réponds-y, ça ne sert à rien que j'écrive plusieurs fois la même chose.

            Ton sync ne sert à rien s'il est effectué après le démontage (vu que le démontage provoque l'écriture des buffers "sales" sur le périphérique).

            Comme déjà dit plus tôt, je n'ai pas trouvé de preuve définitive là-dessus. Tu en as ? Je veux bien un extrait de SUS, POSIX ou bien une doc noyau et/ou un post LKML de quelqu'un de connu.

            Cela dit, et pour éviter toute confusion, j'aimerais que tu aies raison, cependant je n'en suis pas sûr pour l'instant, ni d'un point de vue logique (argumentaire déjà exposé) ou pratique (cf. paragraphe précédent).
    • [^] # Re: cache

      Posté par  (site Web personnel) . Évalué à 2.

      Un deuxième argument en faveur du "sync", c'est que au moment où tu est pressé et que tu veux débrancher ta clef USB et partir prendre ton train, il faut attendre le umount plusieurs minutes pour que les données daignent finalement être copiées pour de vrai sur la clef USB.
      • [^] # Re: cache

        Posté par  . Évalué à 4.

        NON !

        le système de fichier fat n'honore pas le -o sync dans son implémentation actuelle sur linux !!

        Regarde les sources et tu verra. Mandrake, dans la 10.1, qui n'utilise plus supermount pour les clé usb ( car ca revient à monter/démonter la clé a chaque accès ) a du patcher le noyau pour faire un pseudo-sync ( à ce que j'ai compris, il sycronise la fat à chaque fermeture de fichier, sinon, le fichier est écrit, mais pas l'entrée dans la fat )
        • [^] # Re: cache

          Posté par  (site Web personnel) . Évalué à 2.

          le système de fichier fat n'honore pas le -o sync dans son implémentation actuelle sur linux !!

          ce qui est très con c'est qu'il ne refuse pas cette option. voire même un petit printk au montage ?
        • [^] # Re: cache

          Posté par  (site Web personnel) . Évalué à 2.

          Je ne sais pas quel est le patch inclus dans le noyau Debian, mais en tout cas l'option sync change beaucoup de choses !
      • [^] # Re: cache

        Posté par  . Évalué à 4.

        Mais de toute façon il faut bien attendre que les données soient écrites.

        Avec sync, le process qui fait l'écriture est bloqué par la vitesse de l'écriture physique, sans sync (donc avec un cache), le process d'écriture est très vite terminé, mais les données sont en cache, Ensuite le cache se vide, dès que le noyau a le temps, cad quasi immédiatement, mais ça prend le même temps d'écriture. L'overhead rajouté par la mise en cache est probablement ridicule par rapport aux temps de transfert - et c'est vrai aussi pour les disques durs plus rapides que les clefs USB qui sont de toute façon largement plus lent que les caches en RAM, c'est bien pour ça que tous les accés disques sont buffeurisés.

        Donc avec ou sans sync, de toute façon il faut attendre que la loupiotte s'éteigne définitivement pour être sûr que tout a été écrit. Et même sous Windows il y a une icône pour "démonter" la clef, et contrairement à certains je pense que Windows utilise également un cache, mais peut-être qu'il se vide plus tôt sur la clef que sous Linux.
  • # Carte réseau USB : pas mieux

    Posté par  . Évalué à 1.

    Surement HS, mais c'est pour la bonne cause, je me lance :
    C'est marrant, j'ai un problème similaire avec une carte réseau USB sur une de mes machines (plus de PCI de libre). J'ai des NETDOG WATCH timeout, dès que je dépasse les 10/20 Ko/s, la carte est complètement figée. Une demande de transfert vers 64 Ko/s, et la carte fige automatiquement quelques secondes plus tard.
    J'ai "gruiké" les sources du module pour mettre le timeout de HZ*10 à HZ*30, mais maintenant c'est pppd qui timeout, donc le problème est juste déplacé.

    Le bug est connu, il s'agit d'u bug #2472 [1]

    La valeur du MTU de l'ethernet est de 1500, proche du 2048 de cp (ou alors j'ai pas tout suivi). Est ce que c'est possible qu'il ya un rapport plus "haut" (couche USB, etc...) ? [2] J'ai aussi remarqué autre chose que je n'ai aps pu tester via le script (pas de clef USB). Le débit de "plantage" est +/- variable suivant la charge de la machine, me faisant penser à un problème de latence. Quelqu'un peut confirmer ?

    Autre idée reçue : l'USB est un bus Universel, donc il est assez verbeux. Obtenir 1 Mo/s sur de l'USB1 tient de l'exploit. Une fois je m'étais amusé à calculer la bande passante réelle en virant le "protocole", j'avais pas plus de 60 %)

    [1] http://bugzilla.kernel.org/show_bug.cgi?id=2472(...)
    [2] Je suis à la recherche d'informations complémentaires pour essayer de debuguer.
  • # Parse error

    Posté par  . Évalué à 1.

    Le script n'a pas l'air d'être ok :-/


    USB key device= [/dev/sda1] ?
    Testing write speed with a kB file...
    blocksize=512 ...(standard_in) 1: parse error
    kB/s
    blocksize=1024 ...(standard_in) 1: parse error
    kB/s
    blocksize=2048 ...(standard_in) 1: parse error
    kB/s
    blocksize=4096 ...(standard_in) 1: parse error
    kB/s
    blocksize=8192 ...(standard_in) 1: parse error
    kB/s
    blocksize=16384 ...(standard_in) 1: parse error
    kB/s
    blocksize=32768 ...(standard_in) 1: parse error
    kB/s
    blocksize=65536 ...(standard_in) 1: parse error
    kB/s
    blocksize=131072 ...(standard_in) 1: parse error
    kB/s
    blocksize=262144 ...(standard_in) 1: parse error
    kB/s
    blocksize=524288 ...(standard_in) 1: parse error
    kB/s
    blocksize=1048576 ...(standard_in) 1: parse error
    kB/s
    normal copy operation with 'cp'... (standard_in) 1: parse error
    kB/s
    • [^] # Re: Parse error

      Posté par  (site Web personnel) . Évalué à 2.

      Reessaye avec
      sh -x usb-storage-benchmark.sh
      • [^] # Re: Parse error

        Posté par  . Évalué à 1.

        le résultat du debug pour un blocksize (après c'est la même chose pour les autres, évidement).

        blocksize=2048 ...+ mount -o sync /dev/sda1 /mnt/test14353
        ++ /usr/bin/time -f %e dd if=/bin/bash of=/mnt/test14353/test14353 obs=2048
        ++ tail -1
        + time=8.93
        ++ echo /8.93
        ++ bc
        (standard_in) 1: parse error
        + speed=
        + echo ' kB/s'
        kB/s
        + rm -f /mnt/test14353/test14353
        + umount /mnt/test14353
        + blocksize=4096
        + '[' 4096 -le 1048576 ']'
        + printf 'blocksize=4096 ...'
        • [^] # Re: Parse error

          Posté par  (site Web personnel) . Évalué à 2.

          il ne calcule pas correctement la variable $filesize.
          Que donne :
          ls -s /bin/bash |cut -d' ' -f1
          ?
          • [^] # Re: Parse error

            Posté par  (site Web personnel) . Évalué à 2.

            /bin/ls plutôt que ls éviterait d'être dans un alias qui potentiellement peut foutre la merde. à essayer chez le monsieur.
            • [^] # Re: Parse error

              Posté par  . Évalué à -1.

              le monsieur a essayé et ca ne change rien :-)
              mais la précaution du filepath complet est qd même nécessaire.

              Ah le shellscript, quelle bouse ... entre les retours de lignes qui posent probleme, les ";" mals place après les "if", les [[]] et les "test" ...
          • [^] # Re: Parse error

            Posté par  . Évalué à 1.

            ca me donne la chaine vide.

            Par contre le "ls -s /bin/bash |cut -d' ' -f2", me donne bien la taille (ya un espace devant).
            • [^] # Re: Parse error

              Posté par  (site Web personnel) . Évalué à 2.

              ok, donc il vaut mieux mettre ça :
              filesize=`ls -s $infile |awk '{print $1}'`
              • [^] # Re: Parse error

                Posté par  (site Web personnel) . Évalué à 1.

                fais gaffe tu te rapproches dangereusement d'un vrai langage de script là.
              • [^] # Re: Parse error

                Posté par  (site Web personnel) . Évalué à 2.

                filesize=$(stat -c "%s" "$infile")
              • [^] # Re: Parse error

                Posté par  . Évalué à 2.

                un peu H.S.

                Tu devrais peut être utiliser #!/bin/bash plutôt que #!/bin/sh, car tu utilise des opérations propre à bash, comme par exemple l'expansion arithmétique: $(($blocksize*2)). Il y a moins de risque d'erreur si le shell par defaut n'est pas bash.

                Avec l'excellentissime vim, on voit dessuite ce genre d'erreur, car elles apparaissent sur fond rouge.
                • [^] # Re: Parse error

                  Posté par  (site Web personnel) . Évalué à 3.

                  Sauf que si tu mets /bin/bash, vim continue de mettre ce genre de syntaxe sur fond rouge, ce qui est moins excellentissime.
                  • [^] # Re: Parse error

                    Posté par  . Évalué à 2.

                    C'est juste que vim est un peu long à la détente: il faut fermer et reouvrire le fichier pour qu'il se rende compte que le shebang a changé. Aprés vim prend en compte les petites nuances des différents shell script. Ça fonctionne aussi en zsh, tcsh, etc ...
  • # ouch, c'est lent.

    Posté par  (site Web personnel) . Évalué à 1.

    USB key device= [/dev/sda1] ?
    Testing write speed with a 616kB file...
    blocksize=512 ... 123 kB/s
    blocksize=1024 ... 202 kB/s
    blocksize=2048 ... 291 kB/s
    blocksize=4096 ... 413 kB/s
    blocksize=8192 ... 470 kB/s
    blocksize=16384 ... 517 kB/s
    blocksize=32768 ... 575 kB/s
    blocksize=65536 ... 581 kB/s
    blocksize=131072 ... 616 kB/s
    blocksize=262144 ... 648 kB/s
    blocksize=524288 ... 655 kB/s
    blocksize=1048576 ... 676 kB/s
    normal copy operation with 'cp'... 123 kB/s

    Clé usb targa, sur USB1, en fat32
  • # pas-libre-pas-troll

    Posté par  . Évalué à 3.

    Je me demande si on pourrait pas aller voir ce qui se passe chez Mac OS X... Après tout, je viens de découvrir qu'ils avait mount, mkfs, fsck, ...

    Quelqu'un pour nous (me) dire comment ça se passe de l'autre côté ?
  • # Mon résultat

    Posté par  . Évalué à 1.

    Testing write speed with a 656kB file...
    blocksize=512 ... 676 kB/s
    blocksize=1024 ... 348 kB/s
    blocksize=2048 ... 762 kB/s
    blocksize=4096 ... 800 kB/s
    blocksize=8192 ... 790 kB/s
    blocksize=16384 ... 800 kB/s
    blocksize=32768 ... 771 kB/s
    blocksize=65536 ... 790 kB/s
    blocksize=131072 ... 800 kB/s
    blocksize=262144 ... 762 kB/s
    blocksize=524288 ... 720 kB/s
    blocksize=1048576 ... 771 kB/s
    normal copy operation with 'cp'... (standard_in) 1: illegal character: :
    (standard_in) 1: illegal character: \351
    (standard_in) 1: parse error
    (standard_in) 1: illegal character: `
    (standard_in) 1: illegal character: '
    (standard_in) 1: illegal character: :
    (standard_in) 1: parse error
    (standard_in) 1: illegal character: \351
    (standard_in) 1: illegal character: \351
    (standard_in) 2: parse error
    (standard_in) 2: parse error
    .87 kB/s


    Clef 128Mo 'MARCHI DISK USB2.0'
    (Vieux portable Toshiba, USB 1)
  • # question

    Posté par  (site Web personnel) . Évalué à 1.

    est il possible de creer un média virtuel comme : une clef USB (virtuelle) qui se synchronise lors du chargement de celle ci.
    • [^] # Re: question

      Posté par  (site Web personnel) . Évalué à 3.

      Ca doit être possible en créant un répertoire représentant la clef usb, puis en effectuant une synchro avec unison soit manuellement avec unison-gtk, soit automatiquement avec une ligne de commande unison via un script hotplug ou udev.
      Dans ce cas il faudrait trouver un moyen de limiter automatiquement la taille du répertoire. (sans devoir créer une partition pour ça)
  • # Problème non trivial

    Posté par  (site Web personnel) . Évalué à 3.

    comme j'ai ajouté sur ton wiki:

    cp uses the st_blksize field of the destination to determine 'optimal' block size:
    from fileutils/src/copy.c line ~ 293:
    if (fstat (dest_desc, &sb))
    ...
    buf_size = ST_BLKSIZE (sb);

    set it higher by hand, and cp will get faster with your USB key (and possibly your harddrive too).
    The problem is that this would fix cp, but not other apps using st_blksize to determine such things.

    the ioctl used by fstat to get this is BLKBSZGET, and is handled by drivers/block/ioctl.c.
    Kernel hackers say it is not possible to set a logical block size higher than page_size (which is usually 4k).
    • [^] # Re: Problème non trivial

      Posté par  (site Web personnel) . Évalué à 3.

      Merci,
      c'est ce que j'avais commencé à comprendre ici : https://linuxfr.org/comments/492203.html#492203(...)

      Mais est-ce que le noyau ne pourrait pas déterminer automatiquement ce ioblocksize ? Par exemple en prenant d'abord 512 puis en doublant jusqu'à obtenir le meilleur taux ?
      Ou sinon, il devrait prendre automatiquement ce qui a été spécifié lors du montage avec l'option -o blocksize, mais il n'en tient pas compte.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.