Pour quelle raison (OS, système, programmation, interne) une clé USB doit être éjectée avant d'être retirée?

[grunt2000]

Bonjour,

C'est une petite question à laquelle la nécessité d'une réponse n'est pas critique. Cependant, j'aimerais aller au fond des choses pour comprendre ce qui se passe exactement, si quelques-uns parmi vous le savent.

Nous en sommes tous avertis: avant de débrancher sa clef USB de son ordinateur, sous Windows, il faut d'abord l'éjecter. Faute de quoi, jusqu'à son contenu entier peut être perdu.
Pourquoi donc?

Que se passe t-il qui dépasse l'entendement des fonctions open() et close() débutant et terminant les opérations sur fichiers? Car celles-ci sont toujours appelées par les traitements qui procèdent de la même manière pour faire une copie, un déplacement, un ajout ou une suppression de fichier, et qui par principe ne se préoccupent pas de la nature du support physique.

Alors je m'interroge: quel est le fond du problème? La commande close() qui suit la fermeture d'un fichier cible d'une copie, par exemple, ne le ferme pas dans les faits et si l'on retire la clef, même une minute après la copie tout est perdu? Pourquoi cela aurait-il lieu? Absence de flush? Non, ce serait trop curieux.

Ce doit être des opérations spéciales en initialisation de clef USB, lors de sa reconnaissance qui la rendent instable d'une certaine façon, l'endommagent je dirais, et elle ne serait re-stabilisée ("réparée") que lors de l'opération d'éjection.
Ce qui pourrait impliquer - entre autres - qu'aucun open() ne fait d'open, et aucun close() de close, mais que tous les fichiers sont tous ouverts à l'introduction de la clef, et tous fermés lors de l'action système d'éjection.

Qu'est-ce qui explique précisément, à quelque niveau que ce soit (OS, programmation, système, et interne de l'USB), cette contrainte si spécifique de l'éjection?

En vous remerciant,

Grunt.

[ram-0000]

Peut être effectivement le moyen d'être sûr que le cache des écritures est vidé.

Une autre raison, est que sous tous les autres OS, un disque doit être démonté pour pouvoir être remonté. Sinon, cela se traduit par un fsck ou un chkdsk au remontage.

Peut être que la raison est la même pour les clés USB mais que Microsoft a préféré utiliser le mont "éjecter" plus proche des cd-rom et cassettes et du langage courant que le mot démontage qui pour madame Michu a une toute autre signification.

[ALT]

Quelques précisions, pour fixer les idées.
Sur tous les systèmes multitâches & a fortiori multi-utilisateurs, il faut monter un disque (ou : une clé USB, un CD...) pour l'utiliser & le démonter après utilisation.
Explication :

1. Au montage on annonce au système l'arrivée d'un nouveau périphérique de stockage, on lui indique ce qu'il peut en faire (lecture ou écriture) & où il doit l'insérer dans l'arborescence des fichiers (Unix).
2. À l'utilisation, pour accélérer la disponibilité du système pour les utilisateurs, les opérations de lecture & surtout d'écriture sont mises en cache & effectivement réalisées quand le système est moins occupé.
3. Au démontage, on avertit le système que le volume ne sera plus accessible. Celui-ci avertit les utilisateurs (ou, au choix, contrôle qu'il n'y en a plus pour accepter le démontage), finalise les écritures, ferme tous les fichiers...

C'est bien le démontage qui garantit la cohérence du système de fichiers du périphérique de stockage. Et qui évite donc la perte de données.

[Anikinisan]

De ce que j'en avait compris, c'est effectivement une histoire de cache d'écriture pour des raisons de performance.
Par défaut, Windows n'écrit pas directement sur les clefs USB mais passe par un cache.
Mais sous XP (pas trouvé sur Seven, pas de Vista sous la main pour vérifier...) tu peux configurer ta clef pour ne pas passer par un cache d'écriture et tu ne devrait plus avoir à éjecter ta clef avant de l'enlever. Je n'ai personnellement pas eu le courage de vérifier, je préfère prendre 5 secondes de plus que de me retrouver avec une clef foutue.

Pour changer la stratégie d'utilisation de la clef:
- click droit => "Propriétés" sur le lecteur représentant la clef dans Windows Explorer
- Onglet "Hardware" (4e onglet chez moi)
- choisir la clef correspondante dans la liste puis afficher les propriétés
- Onglet "Policies" (stratégie)
- Choisir "Optimiser pour une suppression rapide"

Petite astuce au passage:
Si je ne peux assurer que ce mode t'affranchit de l'étape d'éjection sans prendre de risques, je sais cependant que dans ce mode, tu peux formater ta clef en NTFS alors que dans l'autre mode tu peux pas.

[fregolo52]

Je confirme vos dires sur le cache !!!
C'est du vécu !!!
j'ai arraché une clé, je me suis reconnecté, et oh misère !!! mes modifs n'étaient pas dedans.

[grunt2000]

Pour autant, quand j'enfiche mon appareil photo, lui aussi est reconnu, me permet de lire et d'écrire, et je l'arrache sans problèmes!

[sevyc64]

Envoyé par grunt2000

Pour autant, quand j'enfiche mon appareil photo, lui aussi est reconnu, me permet de lire et d'écrire, et je l'arrache sans problèmes!

Si ton appareil photo est vu comme un appareil photo, le fonctionnement n'est pas le même.
S'il est vu (ou plus exactement la carte qu'il contient) comme un stockage de masse, tu dois l'éjecter avec de retirer de câble.

Ne pas le faire ne pose, la plupart du temps, aucun problème si c'est retiré longtemps après le dernier accès.
Mais le jour ou tu flingueras ta carte avec toutes le photos dessus, tu vas pleurer.

J'ai connu avec un lecteur mp3

[grunt2000]

Ce que vous dites est juste, mais ne me satisfait pas entièrement.

1) Un cache peut se flusher.
Passé quelques secondes après la dernière écriture, un flush pourrait débuter: ça n'obèrerait en rien les performances de quoi que ce soit. D'autant qu'on peut le constater quand on demande l'éjection: le temps entre la demande d'éjection et l'autorisation de retrait est très court: l'écriture du contenu du cache sur la clef est très rapide.

2) Aucune opération faite et clef arrachée => perte du contenu de la clef?
Il me semble que la seule insertion de la clef et son arrachage avant même la première écriture suffit parfois à rendre inaccessible par la suite son contenu. Mais je peux me tromper. Si j'ai raison, là le cache en écriture n'intervient pas.

3) Pourquoi l'OS ne saurait-il pas garder la clef dans un état valide, tant qu'il n'a pas débuté le flush de son cache en écriture?
J'ai une clef avec la FAT 1 et les données 1.
Le cache propose une FAT 2 avec les données 2.
Tant que le cache n'est pas vidé, si je retire la clef, je dois retrouver en la réinsérant FAT 1 / données 1.
Mais certainement pas perdre son contenu.

4) J'écris quelques fichiers, mais c'est toute la clef qui peut être détruite. Comment expliquer une telle défaite?
Si le cache est entrain de se flusher, la situation est plus problématique. Une partie de la clef va devenir invalide. C'est inévitable. Elle sera en transition entre FAT 1 / données 1 et FAT 2 / données 2 dans un état instable.
Oui, mais seule une partie de son contenu est faux. Une portion de la FAT ne correspond plus à la réalité et une portion des données non plus.

Il n'en reste pas moins attendu que la majeure partie de la FAT et des données qu'elles porte devrait rester indemne.
Si je modifie, supprime, ou ajoute des fichiers ou répertoires, les arborescences non ciblées ne doivent pas être affectées.

Comment s'explique t-il qu'elles le soient?

5) Le montage et le démontage, puisqu'on les évoque, que font-ils exactement? Justement pas de chkdsk.
Vous avez insisté sur les indispensables opérations de montage et de démontage. Mais aucune d'elle n'est supposée par son absence de complétion détruire le contenu de la clef. Ces opérations ne semblent pas capables de sécurisation d'un périphérique USB: elles ne font aucun chkdsk, aucune tentative de reprise de données endommagées. En conséquence, me semble t-il, que l'OS parvient à donner des ordres bas niveau à la clef si terribles qu'ils empêchent par la suite l'OS de comprendre absolument ce qu'il a fait. Ce qui est au vu des points précédents que j'ai soulignés très difficile à tolérer et mérite, à mon avis, des explications approfondies.


Je constate qu'à l'heure actuelle, il faut éjecter sa clef parce que sinon on peut avoir des problèmes.
Ce qui m'intéresse, c'est comment se justifient / se provoquent les troubles qui vont jusqu'à rendre les données de la clef totalement inaccessibles, alors que toute la programmation système que je connais a toujours eu pour vocation la plus grande "prudence" et circonspection possible. Voici que là, on admet la destruction pure et simple de l'ensemble du contenu du périphérique. Admettez que c'est un peu fort de café! Cela m'interroge sur les raisons précises du déclenchement d'une telle catastrophe.

Je souhaite entrer dans l'interne du fonctionnement des différents composants logiciels et matériels engagés pour comprendre de quelle manière a lieu cette perte de contrôle.


Cordialement,

Grunt.

[sevyc64]

1) C'est que qui est fait. Sauf que c'est fait à la discrétion du système d'exploitation. Ca peut se produire quelques dizaines de ms après l'écriture dans le cache à, potentiellement, plusieurs minutes. C'est l'os qui décide selon sa charge et divers autres paramètres.

2) Parce que l'on ne parle pas ici d'opérations faites par l'utilisateur, mais bien d'opérations faites par l'os. A l'insertion de la clé, le système vient faire pas mal de chose sur la clé, dont parfois des écritures sans même que l’utilisateur n'ait encore demandé quoique ce soit.

3) Le problème se situe essentiellement au moment ou le retrait à lieu en pleine écriture. L'utilisateur n'est pas capable de savoir quand l'os écrit, et l'os ne sait pas quand l'utilisateur va retirer la clé, d’où source de conflit inévitable.

4) C'est dû à la structure même de l'organisation des données sur la clé. Tu peux détruire juste une entrée de la table des matière (MFT) et c'est toute la clé qui est inaccessible. C'est exactement la même chose pour les DD, sauf que les DD, on arrête la machine pour le débrancher.

5) Le démontage a pour effet justement de vider le cache et d'écrire physiquement les données sur le périphérique, plus diverses autres opérations. Puis le périphérique est déclaré démonté, donc inutilisable et inaccessible par quelques outils que ce soit. Plus personne ne peut venir lire ou écrire dessus. L'utilisateur est ainsi assuré qu'il peut retirer le périphérique quand il veut, sans risquer de le faire durant une phase d'écriture.

[shawn12]

Outre les problèmes de cache, l'éjection permet aussi de se rendre compte si on a laissé un fichier ou un logiciel ouvert sur la clé. En effet, l'éjection sera impossible parce qu'il y a un descripteur de fichier qui est encore ouvert.