USB copie lente

Support Debian
#1

Debian Wheezy 64 bits kernel 3.2.0-4-amd64

Bonjour,

Au début, je croyais que ça venait de hdparm : usb-write-caching-lent-erreur-hdparm-t48288.html (mon ancien thread, si vous avez du temps à perdre)

Je résume :
-Problème Debian sur n’importe quelle clé USB, en écriture.
-il arrive rapidement à 99% d’un fichier, reste bloqué, puis repart sur un autre au bout de 30 sec-1 min.
-Je pense que le problème est apparu depuis que j’ai formaté une microSD défectueuse mais je n’en suis plus sûr depuis mon ancien thread.
-VMWare ne monte plus aucun périphérique USB à l’intérieur d’une machine virtuelle (Je ne vois même pas de driver de clé USB apparaître dans le gestionnaire de périphérique windows xp virtuel).
-J’ai créé un nouveau compte utilisateur Debian. Le problème est toujours là.
-cp en mode --verbose n’affiche rien de particulier. Pareil en sudo.
-J’ai essayé “sync”, sans résultat.

J’ai démarré sur un live CD Debian.

J’ai voulu connaître la vitesse de ma clé sur Debian liveCD -> vitesse moyenne = 20 Mo/s.
Test sur ma Debian, même clé, mêmes fichiers, même port USB -> vitesse moyenne = 6 Mo/s.

CQFD : j’ai un bug au niveau de l’USB.

Je vais désinstaller fuse et libimobiledevice et libgpod pour voir (outils pour prise en charge des idevices).

J’ai vu une autre personne qui avait le même problème sur un autre forum. Il est direct passé par la case “réinstallation de Debian”.
Si possible, j’aimerais éviter ^^. (ou alors retrouver tous mes programmes déjà installés après)

Merci d’avance pour votre aide.

cat /proc/mounts |grep "sdc" /dev/sdc /media/macle vfat rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=cp437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro 0 0

#2

Tu as plusieurs choses à regarder:

  1. Est ce un problème au niveau du noyau ou au delà. Tu peux faire un test direct via un

time dd if=/dev/zero of=/dev/sdb bs=1M count=100

Tu auras une idée du débit.

  1. Tu peux voir avec un CD live ou un autre OS si le pbm vient de ton installation ou si c’est un pbm hard.

  2. Si il se confirme que c’est un souci de ta machine, tu peux essayer de voir les fichiers modifiés dans le système depuis ta manoeuvre avec la sdcard via un find

find /etc /usr /bin /lib -ctime -30

te donne ce qui a été modifié depuis moins d’un mois dans les répertoires indiqués.

#3

Salut,

D’abord, merci de m’avoir donné des pistes ^^.

Voilà ce que donne la commande

[code]time dd if=/dev/zero of=/dev/sdb bs=1M count=10000
1027+0 enregistrements lus
1027+0 enregistrements écrits
1076887552 octets (1,1 GB) copiés, 167,671 s, 6,4 MB/s

real 2m47.705s
user 0m0.000s
sys 0m0.852s[/code]

Je n’ai pas pu désinstaller fuse,…
Problème de dépendances de Gnome.

J’ai déjà testé le live CD. (cf. message)
-> pas un problème hardware.

La dernière commande m’affiche tellement de lignes qu’une vie humaine ne me suffirait pas pour les lire xD.
En gros, sont présents :
le kernel 3.2.0-4 (je me souviens l’avoir mis à jour via dépôts, mais bizarre : passé de la version 3.2.0-4 à 3.2.0-4 ???)
linux-headers
linux_x86_64

#4

Ya du nouveau !

[strike]Tout à l’heure, j’avais pas remarqué que la commande faisait intervenir dd.
Je l’ai lancée sur ma clé USB quotidienne like an idiot.[/strike]
J’ai donc dû la formater après (t’inquiète pas, j’avais un backup :slightly_smiling:).
En refaisant un test de copie, la vitesse est normale !?

Je prends donc une de mes clés USB formatée avec Windows pour voir si c’est résolu.
Non.

Alors, je me demande ce qui diffère entre formatage windows-linux :

[code]Gestion des disques

Clé rapide :
Type de partition : W95 FAT32 (LBA)(0x0c)
Type : FAT (version 32-bit)

Clé lente 1 :
Type : FAT (version 32-bit)

Clé lente 2:
Type de partition : W95 FAT32 (0x0b)
Type : FAT (version 32-bit)[/code]

Sur ce, je me laisse pas abattre et je fais un test de copie sur clé lente sur mon ordi portable Debian, mis à jour régulièrement aussi.
Même problème que mon fixe.

Serait-ce un bug du nouveau kernel ? Faut-il le rapporter ? -> Debian 6 en live CD copie à grande vitesse sur mes clés Windows.
Est-ce que vous avez le problème vous aussi avec des clés formatées sous Windows ? -> copie à 1/4 de la vitesse nominale

#5

Le dd indique donc que ça n’est pas un problème du noyau puisque (si j’ai bien compris) la vitesse est normale et que ça a même fonctionné correctement. Cela veut dire que ça n’est pas un problème de l’USB.

Le fait que ça le fasse avec des clefs formattées sous Windows montre plutôt un pbm du vfat, peut être au niveau du noyau. Essaye de te récupérer le vieux noyau pour voir si cela vient du module vfat.

Est ce que le problème a lieu sur des clefs formattées en ext3 ou en msdos?

#6

Hello,

FAT32 windows : bug
FAT32 linux : ok
ext3 : ok
NTFS : meilleur score

Le problème dans VMWare a l’air d’être interne à ma VM : le montage fonctionne sur VM Ubuntu.

J’essaierai, quand j’aurai le temps, de trouver un ancien noyau (ça marche via apt-get ?).

J’aimerais juste que quelqu’un me confirme que le ralentissement de la copie sur FAT32 type windows affecte la communauté entière.
(Eventuellement s’il faut soumettre un rapport de bug aux développeurs)

Merci

#7

Que donne fdisk -l sur une clef FAT32 rapide vs une clef FAT32 lente?
Je soupconne une géométrie différente

#8

clé rapide

[code]Disque /dev/sdc : 32.0 Go, 32010928128 octets
64 têtes, 32 secteurs/piste, 30528 cylindres, total 62521344 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00010c53

Périphérique Amorce Début Fin Blocs Id Système
/dev/sdc1 32 62521343 31260656 c W95 FAT32 (LBA)[/code]

clé lente 1

[code]Disque /dev/sdd : 16.0 Go, 16039018496 octets
64 têtes, 32 secteurs/piste, 15296 cylindres, total 31326208 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x69642073

Cela ne ressemble pas à une table de partition.
Vous avez probablement sélectionné le mauvais périphérique.

Périphérique Amorce Début Fin Blocs Id Système
/dev/sdd1 ? 1679830642 3650200026 985184692+ d Inconnu
/dev/sdd2 ? 544892275 1088410599 271759162+ 50 OnTrack DM
/dev/sdd3 ? 544372079 2731989728 1093808825 68 Inconnu
/dev/sdd4 ? 2885681152 2885734593 26721 65 Novell Netware 386

Les entrées de la table de partitions ne sont pas dans l’ordre du disque[/code]

clé lente 2

[code]Disque /dev/sdd : 8022 Mo, 8022654976 octets
255 têtes, 63 secteurs/piste, 975 cylindres, total 15669248 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d’E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x00063d6c

Périphérique Amorce Début Fin Blocs Id Système
/dev/sdd1 * 63 15663374 7831656 b W95 FAT32[/code]

#9

La deuxième clef n’est pas partitionnée, la 3ième a une structure qui me parait standard (c’est celle que j’utilise pour clefagre), la deuxième n’est pas partitionnée. Essaye de faire la chose suivante:

Sur la deuxième clef, tu crée une partition de format FAT32 (type 0c ou 0b) et tu la formattes sur Windows, puis tu regardes le débit.

Pour la seconde 3ième clef, tu peux faire

Tu vérifies que l’écriture est rapide.
Puis tu la formatte sur Windows et tu regardes si ça reste rapide.

#10

Salut Fran

J’ai essayé d’avoir accès à un PC sous windows pour faire les tests (c’est pour ça que j’ai tant tardé). Je n’en ai pas de disponible sous la main. Peut-être qu’un jour je posterai les résultats ici ^^.

A priori, sous un ancien kernel, mes 3 clés fonctionnent correctement (Debian 6 en live CD).
Il n’y a normalement pas de raison que sur 2 PC différents sous ‘Debian 7 kernel 3.2.0-4’, il y ait le problème.
C’est ce qui me fait penser que c’est aux développeurs de noyaux de résoudre le problème.

T’est-t-il possible de tester une clé USB FAT32 type windows (de préférence XP) sur ta Debian stp ?
Peut-être est-ce un bug à reporter aux devs…

En tout cas, merci pour ton investissement !

#11

J’ai voulu connaître la vitesse de ma clé sur Debian liveCD -> vitesse moyenne = 20 Mo/s.
Test sur ma Debian, même clé, mêmes fichiers, même port USB -> vitesse moyenne = 6 Mo/s.

moi, j’utilise ( suse studio imagewriter ) qui est tres rapide …

pour le download d’imagewriter en deb :

sourceforge.net/projects/linuxfr … b/download

#12

Tu n’utilises pas les mêmes clefs pour faire les tests …
Scoop: les clefs USB sont lentes.

Fait attention à la bufferisation.

#13

@webby et haleth
C’est un peu délicat de vous le demander : j’aimerais que vous preniez connaissance du sujet dans sa globalité avant de répondre svp.
(non, je ne recherche pas de liveCD - et encore pire, je suis au courant que j’utilise différentes clés pour faire mes tests - puisque ce sont des tests)
Sinon, merci de vous intéresser à mon problème.

D’accord, mais comment la contrôler ?

Si quelqu’un pouvait faire une copie et me dire si elle est anormalement lente : //par rapport au NTFS ou FAT32 de Debian
-Debian 7 kernel 3.2.0-4
-Sur clé USB FAT32 formatée avec Windows (de préférence XP)
-Fichiers de l’ordre de 200 Mo chacun

Je voudrais m’assurer que ce bug touche la communauté entière avant de le reporter aux devs.

#14

[quote]
D’accord, mais comment la contrôler ?[/quote]
sync avant/après la copie;
Avec dd :

dd if=machin of=truc bs=4M conv=fdatasync

sync permet de forcer le flush des buffers, c’est pour cela “que la copie est rapide, puis attend 30sec”. C’est rapide de remplir les buffers, mais la copie est lente par la suite, car il faut les vider.