[Réglé] Vitesse de tft clé USB sous Suse 10.0, 40 ko/s ! Options

[Slyce]

Bonjour,

Je rencontre un petit problème sur ma Suse 10.0. Mon lecteur MP3 est en fait une clé USB avec un partition de type VFAT. Quand je la branche, ma partition est détectée sur /dev/sda (et pas sda1, l'espace n'est pas partitionné avec des partitions primaires/logiques, c'est bien le disque lui-même qui contient un système de ficheir vfat).

Ma Suse détecte tout, monte la clé sous /media/usbkey, puis sous KDE la fenètre s'ouvre. Classique jusqsue là. Quand je copie des fichiers (mp3 ou autre) sur cette clé, je cartonne à la haute vitesse de ... 40 ko/s ! J'ai essayé sur mon portable, même vitesse ! Avec un Suse 9.3 (sur une autre partition) la vitesse est supérieure à 1Mo/s !

Rencontrez vous ce problème de vitesse de transfert ?

EDIT ! Le bug est référencé : https://bugzilla.novell.com/show_bug.cgi?id=105871

Oui mais voila, ils indiquent qu'ils attendront la 10.1 pour corriger ! Vous y croyez ??? Galagann, crois-tu que Alionet et Slyunix, ensemble, pourraient tenter de coller la pression à Suse pour corriger, sachant qu'ils savent comment faire, dans la 10.0 ?

[Slyce]

Bon c'est un duplicate de http://www.alionet.org/index.php?showtopic=5936

cependant je pense qu'une action est possible.

[galagann]

Salux,

Comme, je le dis dans l'autre topic, c'est certainement un erreur de compilation dans le Kernel et qu'une mise à jour va être mise en place qu'ici très peu de temps car un BugList est ouvert.

[cheshire]

Bonjour,
Quand on n'a pas de connection internet avec sa Suse, comment faire pour avoir une liste des mises à jour possibles, où les télécharger et comment les installer ?

Le site de Novell n'a pas l'air de donner des correctifs à partir de la Suse 10.

Ils seront sur Opensuse.org ?

[Copernicus_Thebi...]

40 ko/s ... tu en as de la chance Slyce .... j'suis qu'a 27 ko/s au maximum .. avec mon lecteur mp3... (IMG:http://www.alionet.org/style_emoticons/default/sad.gif) (IMG:http://www.alionet.org/style_emoticons/default/sad.gif) .. par contre avec ma clé USB tout va bien ... c'est cela que je trouve bizzard ...

[Slyce]

Voici un hack proposé sur Bugzilla. ATTENTION ! Il vire la syncro, aussi il ne faut surtout pas débrancher tout de suite la clé ou le lecteur MP3 après des écritures (en cas de doute : sync).

1. Create the directory /usr/share/hal/fdi/policy/95userpolicy:

mkdir -p /usr/share/hal/fdi/policy/95userpolicy/

2. Create a file with the name nosync.fdi and the following contents:

vi /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<!-- disable sync for mount -->
<match key="block.is_volume" bool="true">
<match key="volume.fsusage" string="filesystem">
<match key="volume.uuid" string="==UUID==">
<merge key="volume.policy.mount_option.sync" type="bool">false</merge>
</match>
</match>
</match>
</device>
</deviceinfo>

3. Adjust the line <match key="volume.uuid" string="==UUID=="> according to your hardware. Run 'lshal' to retrieve the "volume.uuid" and enter this id instead of ==UUID==

4. Finally restart the HAL service with

rchal restart


Le UUID indiqué ci-dessus c'est pour un seul périph USB. Si vous voulez désactiver le sync pour tous, alors remplacez

<match key="volume.uuid" string="==UUID==">

par

<match key="@info.parent:storage.bus" string="usb">

et c'est tout bon.

[cheshire]

J'ai suivi la méthode donnée dans Bugzilla et rappelée plus haut mais je n'ai pas d'amélioration du débit.

J'imagine qu'il y a pas mal de gens qui l'ont testée (à peu près tous ceux qui ont une clé USB). Cela marche-t-il chez vous ?

Pour information, la solution était signalée dans les realease notes de la SUSE 10.0, mais avec des noms de fichier et dossier différents.
Avec les noms différents, ca ne marche pas mieux.

Je trouve ce bug très embêtant, il faudrait encore que j'essaie le montage/démontage manuel, mais ca rend l'utilisation de la clé moins pratique.

[galagann]

Alors, cela donne quoi ?

[Slyce]

Le hack fonctionne chez moi, mais en partie. En gros ça vire le SYNC, mais comme de toute façon on ne peut pas débrancher la clé USB tant que ce n'est pas synchronisé, il faut tout de même attendre.

Perso après la copie je fais un "sync" manuel, et du coup ça fige un certain temps la fenètre Konqueror de ma clé...

[cheshire]

En démontant puis remontant manuellement en root, j'arrive à avoir une grande vitesse, mais par contre, pas moyen d'utiliser Hal sans la syncro...

[Guest_yann117_*]

J'ai tenté le meme contournement, à la nuance près que j'ai viré le sync sur tout les périphérique USB.

Résultat identique, la copie d'un fichier de plusieurs centaines de mega s "effectue" en 2 micro-secondes (autant dire qu'on sait deja que ce n'est que virtuel), puis s'effectue en background a raison de 0.0000001ko/s

La batterie de mon balladeur a le temps de griller trois fois avant que la copie n'aboutisse ...

je vais tenter le démontage remontage manuel en root pour voir ...

(belle saloperie que ce truc la ... va expliquer a un windozien ke c k'un petit bug temporaire ...)

[cheshire]

J'ai réessayé la méthode donnée dans Bugzilla en mettant directement le fichier nosync.fdi attaché dans Bugzilla dans mon dossier /usr/share/hal/...
Et ça marche !

En fait, je pense que j'ai fait la même chose mais il ne faut pas recopier le contenu du fichier en .fdi, il doit il y avoir une ligne non visible par un éditeur de texte classique.

[cobex4]

Tu peux me détailler pas à pas en francais ce qui faus faire ???

[cheshire]

Alors tout d'abord il faut lancer Konqueror en superutilisateur (je sais certains vont critiquer mais quand on est débutant on comprend quand même mieux ce qu'on fait)

- créer le dossier /usr/share/hal/fdi/policy/95userpolicy
- copier le fichier nosync.fdi dans ce dossier
- relancer hal : "rchal restart" en root

Et normalement ça marche.
Attention la synchronisation est enlevée, il faut donc bien attendre entre le moment où on écrit sur le disque et celui où on le débranche.

[Guest_yann117_*]

Pour ceux qui ont fait la manip et qui pensent que ça marche, pouvez vous effectuer un petit test ?

Je voudrais que vous copiez un ou deux gros (très gros) fichiers sur votre clé USB, du genre 300 ou 400 Mo, ensuite vous prenez le chrono, et vous calculez le temps de copie (je suppose en supervisant le clignotement de la lupiote, ou alors avec un moniteur système qui devrait vous indiquez que votre CPU est en WAIT).

Le résultat m'intéresse .... étant donné que chez moi avec des petits fichiers la bidouille est OK, mais avec des gros fichiers ... ça rends bien sur la main direct, mais la copie se fait a klk pauvres kilos secondes (en gros des heures pour remplir 512Mo) ......

Merci !

[Guest_Mike025_*]

J'ai fait la manip :
515,4M en 5mn20s
Puis freeze de konqueror quelques secondes !!
Enfin retour a la normale.

[cobex4]

Moi sais simple, j'ai rien capté de la manip.... (IMG:http://www.alionet.org/style_emoticons/default/sad.gif)

[cheshire]

Alors je reprends :

-menu "demarrer" -> systeme -> gestion des dossiers (?) -> konqueror en mode superutilisateur
- mot de passe root
- aller dans le dossier /usr/share/hal/fdi/policy/
- click droit -> nouveau -> dossier
- le nommer 95userpolicy
- click droit sur ce lien, enregistrer la cible du lien sous ... (Bureau par exemple)
- renommer le fichier attachment.cgi en nosync.fdi
- glisser le fichier nosync.fdi du bureau vers le dossier 95userpolicy
- ouvrir une console, taper su, puis le mot de passe root, et enfin taper "rchal restart"

Ca devrait suffir pour que l'écriture sur la prochaine clé branchée soit rapide.

EDIT : Moi aussi j'ai un freeze de Konqueror quelques secondes, mais rien de bien méchant

[priape2]

Excellent tout ça, merci beaucoup cheshire (IMG:http://www.alionet.org/style_emoticons/default/thumbup.gif)

[cobex4]

Trop génial l'explication grand merci (IMG:http://www.alionet.org/style_emoticons/default/smile.gif)

Je suis passé de 35ko/s à 5.7 mo/s en écriture sur ma clé USB 1go....