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 de 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 faire les écritures apparaissent plus lent ou plus rapide

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 autrement de la RAM "vide" pour mettre en cache les opérations de lecture / écriture et les rendre plus rapides lors des accès suivants. Le comportement que vous observez met en cache des opérations de copie sur des périphériques lents - la "fin rapide" consiste en fait à écrire dans le cache, puis elle ralentit et s’arrête car le vidage effectif des données du cache (synchronisation) sur le périphérique lent a lieu. 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 n'attend parfois pas la synchronisation et déclare le travail terminé dès que les données sont écrites 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.

• Un SSD, en revanche, contient un contrôleur qui écrit sur les puces de la mémoire flash en parallèle , augmentant 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 disque SSD contient également une mémoire cache RAM (comme les disques durs), ce qui lui permet de stocker rapidement les données entrantes dans la mémoire cache et d’en informer le système d’exploitation, sans avoir à écrire ces données dans 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 les oranges et les 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, d'une taille supérieure à la quantité de RAM du 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 7500 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-le largetestde la clé USB sur votre disque dur. Redémarrez à nouveau (pour le retirer du cache). Formatez ensuite la clé USB (même vfat / FAT32!) Et copiez-la largetestdu disque dur vers la clé.
• Comment se comparent les temps?

J'ai trouvé le correctif que tout ce que j'ai fait était le démontage, le retrait du lecteur et l'exécution sudo modprobe ehci_hcddans le terminal. Insérez le lecteur et agian sudo modprobe ehci_hcdlorsque 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.

Je pense que les chances sont très faibles que ce soit une question de port. Il s’agit plus probablement d’un problème lié à LINUX (ou à la configuration sous Linux). Vous trouverez des milliers de rapports sur les problèmes de lenteur USB dans 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 ....

Juste umountle 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.

Nous sommes en 2019 et j'ai toujours le même problème. J'ai donc pensé chercher une solution sur Internet. J'ai trouvé la page suivante qui en suggère une: https://gist.github.com/2E0PGS/f63544f8abe69acc5caaa54f56efe52f

Ça dit:

Exécutez les commandes suivantes dans une console pour voir si cela résout le problème pour vous. Vous devrez peut-être d' sudo suabord avoir l'autorisation requise.

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

Si cela fonctionne, vous pouvez rendre cette modification persistante lors des redémarrages en collant les deux lignes à la fin de votre /etc/rc.localfichier.

Pour moi, cela a eu l'effet suivant:

Avant de copier des fichiers volumineux sur un lecteur USB, le démarrage serait très rapide (60 Mo / s, par exemple) et deviendrait de plus en plus lent (<10 Mo / s) jusqu’à ce que l’apparence ne se termine jamais.

Maintenant, il commence plus lentement, mais devient de plus en plus rapide et se termine plus tôt qu'auparavant. Cela semble donc "résoudre" le problème ou du moins avoir un effet positif.

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 en arrière.

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.

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

J'ai également eu ce problème, mais j'utilise la commande cp et vous mettez à jour votre clé USB en quelques secondes;

cp -r -u /home/user/Muziek/ /media/user/Audiousbsti
cp -r -u /home/user/Muziek/ /media/user/4F49-4A65/

Je pense que c'est une réponse très tardive mais elle reste ouverte.

D'accord, j'ai eu le même problème pendant trois jours et comment j'ai réussi à sauvegarder mon disque dur de 1 To en utilisant rsync, je sais qu'il est utilisé pour la sauvegarde, mais le travail a été effectué, même lors du transfert de gros fichiers, je l'utilise pour faire ce travail. Si vous souhaitez l’utiliser avec une interface graphique, je vous suggère d’installer Grsync, qui est une version graphique de rsync puisque rsync s’exécute sur le terminal.

J'espère que cela a aidé