Dispositif USB

Support Debian
#1

Bonjour,

J’ai un soucie avec une clé USB et l’information que je dois lire dessous. Sur la clé USB il y a un fichier txt qui je dois lire. Ce fichier et actualiser pour la clé USB automatiquement et périodiquement. Ce une clé USB particulier parce que elle a une système qui permet d’effacer le fichier txt et créer un nouveau avec nouvelle info. Le but et lire le fichier chaque foi il est crée mais chaque occasion que j’essai de le lire il me montre la information du précédent fichier.

Est-ce que vous connaissez une façon où je peux lire le fichier actuel et pas l’ancienne.

Details:
OS debian Wheezy
Raspberry Pi

Je vous remercie.

Juan Pablo.

#2

C’est visiblement de ce côté qu’il faut creuser.
Peux-du nous en dire plus sur cette clé USB. Quelles sont ses caractéristiques?

#3

Déjà tu es dans la mauvaise section, il fallait poster dans “Support Debian”

Ensuite si quand tu li le fichier et que ça te sort des info périmé, c’est que ton fichier n’est pas où mal mis à jour.

#4

Ça me fait penser à la commande “sync”, à utiliser juste après l’écriture du fichier:

#5

[quote=“MicP”]Ça me fait penser à la commande “sync”, à utiliser juste après l’écriture du fichier:

Est-ce que tu peux expliquer un peu plus ton idée? s’il te plait.

Pour répondre à la question sur le type de clé USB : Elle est une clé USB diviser en deux parties. La première partie reçoit information x d’une carte wireless. L’information x est stocké sur la clé USB dans un fichier .txt. Ensuite la clé USB (class mass storage) dois se communiquer avec la Raspberry pi afin de donner l’information qu’il y a dans le fichier txt.

Je vous remercie par avance.

#6

Bonjour,

De ce que vous écrivez, je comprends que l’information contenue dans le fichier .txt est écrite sans passer par le système d’exploitation.
Dans ce cas, il est “normal” que vous relisiez toujours la même information : le noyau a mémorisé la valeur lue la première fois, et n’étant pas averti de la modification du contenu, il vous restire à chaque fois la même information.

J’ignore s’il existe un moyen de signaler au noyau qu’il doit réinitialiser ses tampons.
Peut-être en mettant à jour la date de dernière modification du fichier dans le système de fichier en même temps que vous y écrivez les nouvelles informations.

Cordialement

Dominique

#7

[quote=“Juan Pablo”]… Est-ce que tu peux expliquer un peu plus ton idée? s’il te plait. …
[/quote]
Ce à quoi je pensais, c’était que les données à écrire sur la clef USB devaient sans doute être relues dans le tampon entrée/sortie alors qu’elles n’ont pas encore étés physiquement transférées dans la clef.
De ce fait, c’est le contenu du tampon de sortie de la dernière opération de lecture de la clef qui est relu,
étant donné qu’il n’avait pas encore été physiquement modifié sur la clef durant la précédente demande d’écriture par le noyau.
Je m’explique sûrement mal vu que j’ai plutôt la tête dans la brume ce matin …
Mais jette un Œil au lien suivant :E/S tamponnées

Ensuite, il faudrait regarder le “man” de la commande “sync”.

#8

Merci Dominique pour ta réponse,

Je suis en train de lire sur la commande sync et vérifier si je peux l’utiliser pour résoudre l’inconvénient.

Qqn m’a dit que je pouvait utiliser la commande mount et umount pour actualiser l’information de l’USB. Que est-ce que tu en penses? Moi je pense que ça peux diminuer la performance du système.

Merci

#9

Bonjour,

Je suis aussi intéressé par le résultat, parce ce que je crains que sync n’ait pas d’effet dans le cas présent, car il sert à écrire sur le disque.

[quote=“Juan Pablo”]
Qqn m’a dit que je pouvait utiliser la commande mount et umount pour actualiser l’information de l’USB. Que est-ce que tu en penses?[/quote]

Cela aura probablement plus d’effet que sync, bien que le noyau puisse potentiellement détecter que la clef n’a pas évolué, et que par conséquent il n’est pas nécessaire de remettre à jour les informations.

Probablement. Mais ne vaut-il pas mieux un système qui marche “moins bien” qu’un système qui ne marche “pas du tout” ?

Autre piste potentielle : lire directement le support en mode brut (“raw”) sans passer par le système de fichier, en association avec les “ioctl” qui vont bien. Sans garantie parce que je n’ai jamais fait cela.

En fait, j’ai l’impression que vous cherchez à contourner linux pour accéder aux informations de votre clef. M’est avis que linux ne se laissera pas faire. :confused:

La seule solution qui me semble viable est l’écriture d’un pilote spécifique pour votre matériel : on retombe sur un de vos fils précédents.

Cordialement

Dominique.

#10

D’accord avec ce qui a été dit, l’approche est mauvaise. Un système de fichiers standard stocké sur une mémoire de masse (FAT, ext2/3/4…) monté n’est pas censé être partagé et modifié par autre chose que l’OS qui l’a monté.

#11

[quote=“miko”]… je crains que sync n’ait pas d’effet dans le cas présent, car il sert à écrire sur le disque. …[/quote]C’est bien ce que j’espérais que cette commande fasse étant donné que : … alors qu’elles n’ont pas encore étés physiquement transférées dans la clef …
J’avais aussi précisé : … à utiliser juste après l’écriture du fichier …

[quote=“Juan Pablo”]… Ce une clé USB particulier parce que elle a une système qui permet d’effacer le fichier txt et créer un nouveau avec nouvelle info …[/quote]Maintenant, il faudrait que cette commande “sync” existe dans le
"système qui permet d’effacer le fichier txt et créer un nouveau avec nouvelle info"
“système” dont on ne sait encore pour l’instant pas grand chose.

On pourrait aussi utiliser les commandes SCSI-ATA lancées avec le programme “hdparm”, pour ajuster les paramètres: taille de tampon interne, dma, flush etc…
si tant est que l’autre système ne re-modifie pas ces paramètres.

Et même avec tout ça bien configuré, il resterait le problème de synchronisation entre les deux systèmes…
Ce qui, finalement, nous ramène à la conclusion de Pascal :