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(...)
Journal Benchmarkez votre clef USB !
1
nov.
2004
# 404
Posté par Mjules (site web personnel) . Évalué à 3.
[^] # Re: 404
Posté par ccomb (site web personnel) . Évalué à 3.
[^] # Re: 404
Posté par un_brice (site web personnel) . Évalué à 4.
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 un_brice (site web personnel) . Évalué à 4.
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 tuxyl . Évalué à -1.
Dois-je comprendre que tu as lu le code APRES l'avoir executé?
Je suis certainement Parano, mais bon ...
[^] # Re: 404
Posté par un_brice (site web personnel) . Évalué à 3.
C'est juste des hyptohèses.
# "656kB file"
Posté par N. D. . Évalué à 1.
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 Éric (site web personnel) . Évalué à 0.
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 ccomb (site web personnel) . Évalué à 3.
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 plagiats . Évalué à 6.
[^] # Re: mouais
Posté par Sébastien Koechlin . Évalué à 6.
* 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 ccomb (site web personnel) . Évalué à 3.
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 novexz . Évalué à 5.
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 jigso . Évalué à 2.
[^] # Re: mouais
Posté par Jerome Herman . Évalué à 2.
[^] # Re: mouais
Posté par Olivier Jeannet . Évalué à 2.
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 cedric . Évalué à 3.
[^] # Re: mouais
Posté par jigso . Évalué à 3.
[^] # Re: mouais
Posté par novexz . Évalué à 2.
[^] # Re: mouais
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: mouais
Posté par Olivier Jeannet . Évalué à 2.
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 Boa Treize (site web personnel) . Évalué à 5.
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 Éric (site web personnel) . Évalué à 4.
# cache
Posté par TazForEver . Évalué à 3.
[^] # Re: cache
Posté par un_brice (site web personnel) . Évalué à 5.
[^] # Re: cache
Posté par TazForEver . Évalué à 2.
par contre (j'ai pas ma clef sur là), t'as essayé en virant le -o sync, et en supprimant le rm du chronométrage (faire un mount, rm, umount séparé ?)
[^] # Re: cache
Posté par ccomb (site web personnel) . Évalué à 2.
oui, voir : https://linuxfr.org/comments/492316.html#492316(...)
# Résultats
Posté par tipmeabout . Évalué à 2.
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 ccomb (site web personnel) . Évalué à 1.
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 tipmeabout . Évalué à -2.
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 ccomb (site web personnel) . Évalué à 1.
[^] # Re: Résultats
Posté par gasmask87 . Évalué à 1.
# ./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 ccomb (site web personnel) . Évalué à 2.
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 jaroug (site web personnel) . Évalué à 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 ccomb (site web personnel) . Évalué à 3.
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 Guillaume Knispel . Évalué à 2.
Ptet que ca copie par block de 1 ko, je sais pas moi :p
# pour info
Posté par M . Évalué à 3.
Logiquement les perf devrait etre moins bonne qu'avec le usb_storage, mais on ne sais jamais...
# hdparm(8) ?
Posté par Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: hdparm(8) ?
Posté par ccomb (site web personnel) . Évalué à 4.
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"...
[^] # Re: hdparm(8) ?
Posté par scullder . Évalué à 1.
http://scullder.free.fr/php/hdparm.phps(...)
je sais, ça sert à rien... ^_^
# blksize
Posté par ccomb (site web personnel) . Évalué à 5.
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 ccomb (site web personnel) . Évalué à 4.
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 Mathieu Pillard (site web personnel) . Évalué à 2.
Je teste des que je retrouve une clé usb... :)
[^] # Re: blksize
Posté par un_brice (site web personnel) . Évalué à 1.
mkfs.vfat -S logical-sector-size /dev/sda1
[^] # Re: blksize
Posté par ccomb (site web personnel) . Évalué à 3.
[^] # Re: blksize
Posté par un_brice (site web personnel) . Évalué à 2.
Ça a été confirmé par un gars un peu plus loin, sauf erreur.
[^] # Re: blksize
Posté par ccomb (site web personnel) . Évalué à 2.
# cache
Posté par gc (site web personnel) . Évalué à 3.
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 ccomb (site web personnel) . Évalué à 3.
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 gc (site web personnel) . Évalué à 2.
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 Ramso . Évalué à 2.
> 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 ccomb (site web personnel) . Évalué à 2.
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 Olivier Jeannet . Évalué à 5.
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 gc (site web personnel) . Évalué à 1.
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 ccomb (site web personnel) . Évalué à 2.
[^] # Re: cache
Posté par couriousous . Évalué à 4.
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 gc (site web personnel) . Évalué à 2.
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 ccomb (site web personnel) . Évalué à 2.
[^] # Re: cache
Posté par jigso . Évalué à 4.
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 demik . Évalué à 1.
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.
[^] # Re: Carte réseau USB : pas mieux
Posté par ccomb (site web personnel) . Évalué à 2.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245398(...)
J'y ai passé plusieurs dizaines d'heures pour l'instant, mais rien n'est résolu.
[^] # Re: Carte réseau USB : pas mieux
Posté par demik . Évalué à 1.
Chez toi, ça donne quoi en 2.4 ?
[^] # Re: Carte réseau USB : pas mieux
Posté par ccomb (site web personnel) . Évalué à 2.
Tous les 2.6 et les 2.4<=.21 ont le probleme.
(voir le rapport de bogue)
[^] # Re: Carte réseau USB : pas mieux
Posté par ccomb (site web personnel) . Évalué à 2.
# Parse error
Posté par Tony Gencyl . Évalué à 1.
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 ccomb (site web personnel) . Évalué à 2.
sh -x usb-storage-benchmark.sh
[^] # Re: Parse error
Posté par Tony Gencyl . Évalué à 1.
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 ccomb (site web personnel) . Évalué à 2.
Que donne :
ls -s /bin/bash |cut -d' ' -f1
?
[^] # Re: Parse error
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: Parse error
Posté par Tony Gencyl . Évalué à -1.
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 Tony Gencyl . Évalué à 1.
Par contre le "ls -s /bin/bash |cut -d' ' -f2", me donne bien la taille (ya un espace devant).
[^] # Re: Parse error
Posté par ccomb (site web personnel) . Évalué à 2.
filesize=`ls -s $infile |awk '{print $1}'`
[^] # Re: Parse error
Posté par gc (site web personnel) . Évalué à 1.
[^] # Re: Parse error
Posté par Vivi (site web personnel) . Évalué à 2.
[^] # Re: Parse error
Posté par gnujsa . Évalué à 2.
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 Boa Treize (site web personnel) . Évalué à 3.
[^] # Re: Parse error
Posté par gnujsa . Évalué à 2.
# ouch, c'est lent.
Posté par _Hitek_ (site web personnel) . Évalué à 1.
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 LeRat . Évalué à 3.
Quelqu'un pour nous (me) dire comment ça se passe de l'autre côté ?
# Mon résultat
Posté par Bertrand Delépine . Évalué à 1.
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 skeespin (site web personnel) . Évalué à 1.
[^] # Re: question
Posté par ccomb (site web personnel) . Évalué à 3.
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 Colin Leroy (site web personnel) . Évalué à 3.
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 ccomb (site web personnel) . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.