ccomb a écrit 1325 commentaires

t'as essayé en virant le -o sync ?

oui, voir : https://linuxfr.org/comments/492316.html#492316(...)

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.

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.

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.

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 ?)

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.

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

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 !

Je suis aussi en Sid (2.6.8), mais j'ai la même chose sur une FC2.

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.

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.

Zut, je suis trop con. Le script n'était pas au bon endroit. Ca devrait être bon maintenant.

Tout le monde n'est pas prêt à accepter de taper une ligne de commande pour démonter sa clef

Le bug que je trouve le plus chiant, qui n'est d'ailleurs pas spécifique à Debian mais plutôt à Gnome, c'est qu'il est régulièrement impossible de démonter une clef USB avec nautilus à cause de FAM.

C'est le seul truc que je trouve bloquant, mais c'est vraiment bloquant.

Je te recommande de mentir au malheureux employé du service client (qui est probablement sous-payé, exploité et mal formé) en lui faisant croire que tu as encore Windows sur ta machine.

Malheureusement, le premier truc qu'il demande est de cliquer sur le menu Démarrer pour faire ensuite tout plein de tests, et qu'il faudrait connaître à l'avance tous les tests pour pouvoir bluffer.
Et c'est d'autant plus énervant qu'il n'y a pas besoin de démarrer l'OS pour voir que ça ne marche pas. Il suffit de vouloir booter sur un dvd bootable.

Ah tiens, je connaissais pas ssh-copy-id, c'est bien pratique, merci !

Oui, un « prog & » devrait suffire pour que le script de démarrage continue tout seul.

Et peut-être même un « nohup prog & » pour que le programme soit détaché du script qui l'a appelé, pour éviter qu'il ne se termine avec son script parent.

avec --grow, tu dois spécifier une taille obligatoirement, même si c'est zéro.

part /u01 --size=0 --grow --ondisk=sda --fstype ext3

Si jamais tu réussis à avoir /dev/sda,
tu peux installer udev, puis essayer ça
http://ccomb.free.fr/wiki/wakka.php?wiki=UsbMassStorage(...)

Et aussi ça : http://linuxfr.org/~ccomb/4471.html(...)

Effectivement pour du transfert automatique il vaut mieux scp.

Il y a un truc qui s'appelle "gestionnaire de sources de paquetages" ou un truc comme ça dans le "Centre de Contrôle Mandrake". C'est à partir de là qu'il faut ajouter un CD.

non, ça c'est pas bon, ça va tout écraser, et il veut apparamment garder la mandrake.

Il faut redimensionner une des partitions avec le "mandrake control center", créer une partition fat32 ou ntfs dans l'espace vide, puis lancer l'install de XP. Mais le probleme est que l'install de XP est tellement peu souple, qu'elle ne veut souvent pas fonctionner à moins de tout virer...

À mon avis, apprend un peu à utiliser linux, c'est très loin d'être du temps perdu car sa part de marché est en train d'augmenter rapidement. Et il vaut toujours mieux consacrer du temps à apprendre à utiliser un logiciel libre plutot qu'un propriétaire, car tu es sûr que ton apprentissage est perenne : tu pourras toujours continuer à l'utiliser librement, et personne ne viendra un jour t'emmerder en te disant qu'il faut payer 10^x euro pour continuer à l'utiliser ou pour faire une mise à jour obligatoire.

D'autre part, dans la mandrake tu as déjà un grande quantité de logiciels (libres!) pour presque tous les usages, alors que sur un XP tu n'as presque rien, et la logithèque libre est beaucoup moins fournie. Donc tu te sentiras à terme obligé de pirater des logiciels ou dépenser une fortune pour les acheter...

Il vaut toujours mieux être libre et dans la légalité, plutôt que hors la loi et/ou coincé par des programmes et fichiers proprios.

AMuleWeb is an utility that listens for HTTP connections at port 4711 (by default, although it can be changed through Preferences) and allows remote users to control aMule using just a web browser.

http://www.amule.org/wiki/index.php/AMuleWeb(...)

Un truc qui n'est pas sur la liste : Grisbi
C'est de la compta personnelle, mais ça peut très bien servir pour un indépendant.
C'est dispo en général en standard sur toutes les distros (je suppose)
http://grisbi.sourceforge.net(...)

juste pour info, freegica n'est pas libre, et il est même limité (500 ou 10000 mouvements comptables selon la version)

Il commence à y avoir de plus en plus de logiciel libres de compta, gestion d'entreprise, etc.. voir tout en bas de cette page :
http://ccomb.free.fr/wiki/wakka.php?wiki=PossibilitesGnuLinux(...)