Copier sur une clé USB vraiment lent?
Lorsque je copie des fichiers sur un périphérique USB, cela prend beaucoup plus de temps que sous Windows (même périphérique USB, même port), il est plus rapide que les vitesses USB 1.0 (1 Mo/s) mais beaucoup plus lente que les vitesses USB 2.0 (12 Mo/s). Copier 1,8 Go me prend plus de 10 minutes (il devrait durer moins de 3 minutes). J'ai deux clés SanDisk Cruzer 8 Go identiques et le même problème se pose. J'ai un SSD USB de 32 Go dans le port voisin et cela fonctionne à la vitesse attendue.
Le problème qui me semble dans l’interface graphique est que la barre de progression va presque à 90% presque instantanément, s’achève à 100% un peu plus lentement, puis s’accroche pendant 10 minutes. Interrompre la copie à ce stade semble entraîner une corruption à la fin du fichier. Si j'attends qu'il soit terminé, la copie est réussie.
Des idées? sortie dmesg ci-dessous:
[64059.432309] usb 2-1.2: new high-speed USB device number 5 using ehci_hcd
[64059.526419] scsi8 : usb-storage 2-1.2:1.0
[64060.529071] scsi 8:0:0:0: Direct-Access SanDisk Cruzer 1.14 PQ: 0 ANSI: 2
[64060.530834] sd 8:0:0:0: Attached scsi generic sg4 type 0
[64060.531925] sd 8:0:0:0: [sdd] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
[64060.533419] sd 8:0:0:0: [sdd] Write Protect is off
[64060.533428] sd 8:0:0:0: [sdd] Mode Sense: 03 00 00 00
[64060.534319] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.534327] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.537988] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.537995] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.541290] sdd: sdd1
[64060.544617] sd 8:0:0:0: [sdd] No Caching mode page present
[64060.544619] sd 8:0:0:0: [sdd] Assuming drive cache: write through
[64060.544621] sd 8:0:0:0: [sdd] Attached SCSI removable disk
Pourquoi la copie sur mon lecteur USB est-elle si lente sous Linux (et plus rapide sous Windows)?
Raison 1. La mise en cache de fichiers peut rendre les écritures plus lentes ou plus rapides
Le problème qui me semble dans l’interface graphique est que la barre de progression va presque à 90% presque instantanément, s’achève à 100% un peu plus lentement, puis s’accroche pendant 10 minutes.
Une chose à comprendre est la mise en cache de fichiers. Linux (et Windows) utiliseront sinon "vide" RAM pour mettre en cache les opérations de lecture/écriture et les rendre plus rapides lors des accès suivants. Le comportement observé lors de la mise en cache d'opérations de copie sur des périphériques lents est le suivant: la "fin rapide" consiste en fait à écrire dans le cache, puis elle ralentit et s'arrête car le vidage réel des données du cache (synchronisation) sur le périphérique lent est prendre très longtemps. Si vous abandonnez à ce moment-là, les données sont corrompues (comme vous l'avez indiqué) car la synchronisation n'a jamais abouti.
Une telle copie sous Windows peut sembler plus rapide (y compris les vitesses rapportées en Mo/s) car Windows parfois n'attendra pas pour la synchronisation et déclare le travail terminé dès que les données est écrit en cache.
Raison 2. L'écriture d'un grand nombre de fichiers, en particulier de petits fichiers, est lente
Pour copier 1,8 Go
En raison du mode de fonctionnement de la mémoire flash et des systèmes de fichiers, le débit le plus rapide (vitesse) est atteint lors de l'écriture de très gros fichiers. Écrire de nombreux petits fichiers, voire des données mixtes contenant un certain nombre de petits fichiers, peut ralentir considérablement le processus. Cela concerne également les disques durs, mais dans une moindre mesure.
Raison 3. Les vitesses d'écriture d'une clé USB et d'un SSD ne peuvent pas être comparées
J'ai un SSD USB de 32 Go dans le port voisin et cela fonctionne à la vitesse attendue.
Une clé USB de type jardin est généralement composée de puces de mémoire flash écrites en série (séquentielles) et ne possède pas de cache propre.
Par contre, un disque SSD contient un contrôleur qui écrit sur les puces de mémoire flash en parallèle , ce qui augmente le débit d’un facteur 2 ou plus sur la Clé USB.
- Si votre SSD de 32 Go disposait de 4 puces de 8 Go, il serait quand même 4x plus rapide que la clé USB lors de toute opération d’écriture.
- Le SSD aussi contient RAM cache (comme les disques durs), afin qu'il puisse rapidement stocker les données entrantes dans le cache et dire au système d'exploitation que c'est fait, alors qu'il doit encore écrire ces données à la mémoire flash.
Ainsi, avec un fichier volumineux, vos 32 Go avec la structure 4x présumée seraient 4x aussi rapides; avec de nombreux petits fichiers, il serait 10 fois ou plus rapide, car il pourrait les stocker intelligemment dans son cache.
En résumé, ce sont les raisons pour lesquelles la copie de fichiers sur des clés USB peut apparaître plus lentement sous Linux. Est-ce réellement plus lent en raison d'un problème matériel/pilote ou autre chose ...
Faire une comparaison appropriée des vitesses d’écriture entre Linux et Windows
- Tout d'abord, oubliez le SSD pour la raison 3. C'est comme des oranges et des pommes.
- Pour annuler les effets de la raison 1 (mise en cache) et de la raison 2 (petits fichiers), vous devez effectuer un test avec un seul fichier volumineux, supérieur à la quantité de RAM sur le système de test.
- Sous Linux, vous pouvez le créer avec
dd if=/dev/urandom of=largetest bs=1M count=7500, ce qui vous donne un fichier de test de 7 500 Mo. En supposant que votre système dispose de moins de 4 Go de RAM, c'est suffisant. Copiez-le sur une clé Sandisk 8 Go fraîchement formatée et chronométrez-le. - Redémarrez sous Windows et copiez
largetestde la clé USB sur votre disque dur. Reboot again (pour le retirer du cache). Formatez ensuite la clé USB (même vfat/FAT32!) Et copiezlargetestdu disque dur sur la clé. - Comment se comparent les temps?
Je pense que les chances sont très faibles que ce soit une question de port. Il s’agit probablement d’un problème lié à LINUX (ou à la configuration sous Linux): vous y trouverez des milliers de rapports sur le problème de la lenteur de l’USB sous Linux/Ubuntu. Pour moi, c'est presque un obstacle pour linux - j'ai maintenant un Ubuntu 12.04 LTS et j'ai toujours ce problème (donc j'utilise plutôt la configuration Win7 - principalement/uniquement à cause de cela). Ce problème (ou quelque chose ayant des symptômes similaires) existe depuis plusieurs années, apparemment sans solution. Et pendant ce temps, j'ai essayé plusieurs PC physiques avec plusieurs versions différentes d'ubuntu (configuration par défaut) et 2 ou 3 clés USB différentes ....
J'ai trouvé le correctif que tout ce que j'ai fait était de démonter, de retirer le lecteur et d'exécuter Sudo modprobe ehci_hcd dans le terminal. Insérez le lecteur et agian Sudo modprobe ehci_hcd lorsque je mets le lecteur et wow 20/mbs pensais que je voudrais partager. J'espère que je n'ai pas à le faire à chaque fois ... mais ce n'est pas trop difficile ...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177235 dit qu'ils ont corrigé le bogue.
Juste umount le périphérique s'il est déjà monté automatiquement, et montez-le manuellement à /mnt/foldername.
Dans mon cas,
umount /media/usb0
mount /dev/sdb1 /mnt/sam
Après cela, ça va très vite.
Quand vous regardez dans/etc/mtab, voyez-vous que le périphérique a été monté avec l'option "flush"?
Si c'est le cas, cela pourrait être la cause du problème (c'était pour moi). Démontez simplement l’appareil et remettez-le en place, il ne devrait pas être configuré par défaut.
Si vous passez en USB 3.0, vous passerez de 1 Mb/s à 5,8/8mb/s. Je passe à un PCI 3.0 USB et à un disque dur externe et je ne reviens pas.
J'ai eu quelques problèmes également avec le taux de transfert sur un disque externe WD, après l'avoir ouvert dans une fenêtre SO, j'ai toujours utilisé LINUX, après quoi le taux de transfert était de 1,5 MB/s à celui que je démonte sur le disque dur externe, là où il était. en disant que sdb1 était inutilement démonté, il a exécuté un fsck, qui a effectué quelques réparations et ensuite 20Mb/s de taux de transfert à nouveau lors de la copie de sda sur un disque externe. fsck est toujours un risque si vous avez des données, mais cela a fonctionné pour moi, sans perte de données.