Clé USB => Vitesse d'écriture ?

Support Debian
#1

Hello,

J’ai un souci que je n’arrive pas à résoudre.
Comment, on fait pour avoir une vitesse d’écriture normale sur une clé USB sous Debian ?

J’ai testé cette clé en USB 2.0 et 3.0 sous Windows (Crystal Disk Mark) :
USB 3 : read : 79mb/s | write : 36mb/s
USB 2 : read : 33mb/s | write : 30mb/s

Linux ext2/ext4 avec ou sans alignement 128k :
USB 2 : read : 33mb/s | write : 6-7mb/s !

Il faut faire quoi pour augmenter cette vitesse ?
Mon test n’est pas correct ? (dd count=100 bs=1M if=/dev/urandom of=/mnt/test/testfile)

Si quelqu’un a une idée ou sait qu’il y a un souci avec la vitesse d’écriture sur les clés USB ?
Je comptais l’utiliser comme disque dur car tous mes disques lachent les uns après les autres et je cherche des solutions de stockage temporaire où il y a beaucoup de lecture/d’écriture et s’il le faut abuser de la garantie de 360 mois offerte avec cette clé de 32Gb :wink: (Merci WD et l’intellipark qui destroy tous les disques après des milliers de load/unload cycle car WDidle ne marche pas sur certains disques…)

Merci d’avance pour votre aide !

#2

Déjà, teste avec une autre source que /dev/urandom, qui charge fortement le CPU. Par exemple /dev/zero ou un fichier quelconque en RAM (tmpfs). Ici, sur une petite machine certes mais quand même, je lis /dev/urandom à 1 Mo/s maxi contre 1 Go/s pour /dev/zero.

#3

Je sais pas trop comment tester.
/dev/zero me donne 1.4go/sec comme résultat donc je sais pas ce qu’il fait mais c’est pas la vitesse d’écriture réelle sur la clé.

On fait comment pour obtenir un débit avec cp ?
Je suis désolé mais je ne sais pas comment faire pour obtenir le débit en écriture ou avoir une barre de progression comme apt-get par exemple.

Merci d’avance pour ton aide !

#4

Bonjour,

A mon avis, il te faut faire un test avec plus de données pour saturer le cache en écriture et réellement tester la vitesse d’écriture de la clé.

#5

J’ai également constaté des écarts dans la copie de fichier sur un support USB, je me suis dit que cela a un rapport avec la taille du fichier a copier ou peut être des ressources de la machine?

La puissance d’un processeur ou la quantité de RAM sont elles responsables de cette vitesse de transfert?

#6

Ou bien peut-être en (re)montant le système de fichiers avec l’option ‘sync’, s’il la supporte.
Ou en écrivant directement dans le périphérique brut (/dev/sdX), mais cela écrase le contenu.
(Alternative : créer un fichier image totale ou partielle du contenu de la clé (non montée) avec dd, puis la réécrire avec dd. Cela fera la mesure en lecture et écriture.)

#7

Je vais essayé avec dd_rescue, ca donne le débit en live :wink:
Merci pour le tuyau !

PS : J’ai testé “urandom” et j’ai un débit de 7.1mb/s en ram donc c’est bien un souci avec le cpu.

Bon, un test en ext2 aligné en 128k :

tune2fs -l /dev/sdd1 | grep -i 'inode size’
Inode size: 128

dd count=999 bs=1M if=/dev/zero of=/mnt/test/dd oflag=sync
999+0 records in
999+0 records out
1047527424 bytes (1.0 GB) copied, 151.24 s, 6.9 MB/s

Et le même test effectué avant en ext4 : 17.7MB/s.
J’y comprends rien mais tout est très loin de mes tests sous Windows à 30MB/s en écriture :frowning:

Je peux pas copier un fichier plus gros car j’ai plus un seul disque dur donc je peux pas copier des données depuis ailleurs ou faire une image complète de mon stick. J’ai essayé en partie dd_rescue mais pas assez précis :frowning:

Quelqu’un a une idée pour exploiter la vitesse du stick à 100% ???
Ou si quelqu’un a déjà testé en USB 3.0 ? (Pas de port en usb 3.0 sur cette carte-mère malheureusement)

Merci d’avance !

#8

Quelques réflexions :
Tu es sûr que les mesures en écriture faites sous Windows sont fiables ?
Quand je copie un volume important sur ma clé, son voyant d’activité continue à clignoter bien après que l’explorateur ait “terminé” la copie.
D’autre part comme tu l’as constaté, la vitesse d’écriture dépend du type de système de fichiers. Quel était-il pour les mesures avec Windows ? Pas ext2/ext4 j’imagine.
De toute façon pour tester la vraie vitesse d’écriture il faut le faire indépendamment de toute système de fichiers, donc sur le périphérique brut.

[quote=“warnings”]Bon, un test en ext2 aligné en 128k :

tune2fs -l /dev/sdd1 | grep -i 'inode size’
Inode size: 128[/quote]
De quoi parles-tu ? “Inode size: 128” indique la taille des inodes (128 octets), rien à voir avec un quelconque alignement sur 128 Ko.

#9

Oui, je les ai faites avec Crystal Disk Mark en faisant 5 tests de suite d’un fichier de 500mo.
Et, j’ai aussi remarqué ce “bug” de Windows et c’est d’ailleurs pour ça qu’il vaut mieux pas retirer à chaud droit derrière le stick :wink:

Justement, mais quel est le meilleur système de fichier ? Celui où il y a le moins de perte ?
(J’étais en FAT32 je pense, pas vérifier mais je vais quand même pas mettre de la FAT32 pour travailler sous Linux … si ?)
Euh pas vraiment, car j’aimerai que la clé soit rapide lors de l’utilisation réelle et pas juste pour un benchmark.
J’aimerais mettre des VMs dessus donc c’est pour ça que j’ai acheté une clé “rapide” en écriture.

J’ai cherché un peu sur le net et en plus d’un alignement avec fdisk, il conseillait de mettre sur 128 les Inodes aussi mais maintenant je sais pas si cela change quelque chose …
J’utilise les commandes que je trouve pour voir s’il y a des gains de perfs …

#10

Dans tous les cas il faut démonter le volume avant de débrancher le périphérique.

[quote=“warnings”]quel est le meilleur système de fichier ? Celui où il y a le moins de perte ?
(J’étais en FAT32 je pense, pas vérifier mais je vais quand même pas mettre de la FAT32 pour travailler sous Linux … si ?)[/quote]
Les systèmes de fichiers FAT, de par leur structure simple (voire simpliste), sont justement réputés pour leur rapidité en écriture. Pas de journalisation, pas d’inodes…

#11

Oui, j’ai testé en ext2 pour éviter la journalisation mais ça ne semble pas plus rapide que de l’ext4 avec journalisation vu que j’ai fait un mkfs.ext4 de base.

Sinon, j’ai testé en FAT32/NTFS depuis CrystalDiskMark qui écrit directement sur la clé en utilisant le système de fichier. Voilà les résultats :

FAT32
http://www.hostingpics.net/viewer.php?id=646468FAT32.jpg
NTFS
http://www.hostingpics.net/viewer.php?id=628690NTFS.jpg
Linux en NTFS :
1047527424 bytes (1.0 GB) copied, 34.3166 s, 30.5 MB/s

J’ai fait un petit test avec un fichier de 700mb en regardant la clé clignoter.
Cela a pris environ 28sec ce qui me donne un débit d’environ 25mb/sec sur le NTFS.

On est quand même loin des 6-7mb sec de “/dev/zero” :confused:

Tu me conseilles quoi comme système de fichier le plus rapide ? (exFAT ?)

EDIT : Après avoir lu cet article : phoronix.com/scan.php?page=n … &px=OTU5Ng
Je vais finalement passer ma clé USB en NTFS pour ne pas avoir de problème avec les fichiers de plus de 4Go (FAT32) et je ne fais pas confiance à l’exFat pour le moment. Mon test avec DD me donnait du 68.3mb/sec. La copie d’un autre fichier était extrêmement rapide et le fichier avait la même signature md5 mais je ne comprends juste pas comment cela est possible. (~16sec pour ~700mb et c’était une vidéo donc pas de “/dev/zero” …)
Par contre si quelqu’un peut m’expliquer comment des systèmes de fichiers modernes tel que l’ext3/l’ext4 peuvent être plus lent que le NTFS ??? Et c’est pas 1 ou 2mb/sec en moins mais presque 4x plus lent pour l’ext3 et ~1.5x plus lent pour l’ext4 ???

EDIT2 : J’ai encore revu un autre benchmark sur la différence de rapidité entre ext2/3/4, exfat, fat mais l’ext3 est vraiment le plus lent :frowning:
Je ne pense vraiment pas que ce soit l’idéal pour les stick usb/CF. L’ext4 est dangereux car il n’y a presque pas de logiciel pour récupérer ce système de fichier donc il reste la FAT/EXT2/NTFS (l’exFat étant aussi un peu trop nouveau support en beta encore) comme système de fichier “rapide” qui vont plus ou moins utiliser les performances du stick/CF.