Bonjour,
Je ne comprend pas pourquoi le fait de retirer une clé USB sans l'avoir démonté peut corrompre le système de fichier.
Imaginons que je connecte ma clé usb. J'ai dans le répertoire /dev : sdb et sdb1 qui apparaissent, avec une partie de sdb1 qui représente les méta données (nom du fichier, inode…) et l'autre partie de sdb1 qui représente les données. Si je ne crée pas de nouveau fichier dans ma clé USB alors les méta données de sdb1 ne vont pas être modifié et donc je ne risque pas de casser quoi que ce soit. alors pourquoi le fait de retirer ca clé USB sans la démonter est un risque si je n'écris pas sur ma clé.
Merci pour votre aide.
# Pas vraiment un risque si tu n'écris rien
Posté par benoar . Évalué à 3.
Si tu n'écris rien, normalement rien ne va être corrompu : je ne sais pas d'où tu as récupéré cette croyance…
Par contre, il se peut que des applications qui veulent faire des trucs « intelligents » dans ton dos veuillent écrire dessus : dans ce cas, tu peux éventuellement causer une corruption si tu enlèves la clé improprement.
[^] # Re: Pas vraiment un risque si tu n'écris rien
Posté par Tonton Th (Mastodon) . Évalué à 6.
D'accord, mais si tu branches une clef USB, c'est assez souvent pour la lire, et si tu n'as pas utilisé l'option
noatimeau montage, le système va quand même aller toucher à quelques inodes au passage…[^] # Re: Pas vraiment un risque si tu n'écris rien
Posté par bubar🦥 (Mastodon) . Évalué à 5. Dernière modification le 15 octobre 2018 à 22:12.
Et par défaut, de nos jours une clef usb fat/exfat est montée avec, entre autre, les options
flushetrelatime, pasnoatime. Tandisqu'une clef en ext sera montée sans leflush, enrelatimeet avecallow_other[^] # Re: Pas vraiment un risque si tu n'écris rien
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Sous w2k il était courant de casser ses clefs en les retirant à chaud, le système tripatouillait dedans sans rien dire (pas seulement cache et pas de sync) C'est d'ailleurs un des premiers trucs qui m'a épaté sous Linux, à l'époque le système ne touchait jamais si tu n'avais rien demandé.
# si tu n'as rien modifié ....
Posté par totof2000 . Évalué à 2.
… normalement tu ne corrompras rien. Par contre, si tu modifies un fichier existant:
- les métadonnées vont être modifiées, surtout si la taille de tes données change.
- les donées elles-même vont être également modifiées
Comme Linux bufferise les données avant écriture sur disque, le fait de ne pas démonter proprement ta clé avant de la retirer risque de poser problème (à moins d'utiliser la commande sync qui est chargée de vider les buffers disque).
# c'est le cas
Posté par NeoX . Évalué à 3. Dernière modification le 15 octobre 2018 à 16:13.
c'est le cas, si tu n'y touches pas, tu ne crains rien…
mais ce n'est pas parce que TOI tu n'y touches pas, que le SYSTEME n'y touche pas
par exemple ton systeme peut vouloir indexer le contenu de la clef pour permettre de faire rapidement des recherches dessus, donc il lit les données, en ecrits d'autres.
bref, finalement, il faut mieux toujours demander l'ejection du lecteur avant de debrancher la clef.
[^] # Re: c'est le cas
Posté par totof2000 . Évalué à 4.
Pour ma part, je trouve ce comportement à la limite de l'acceptable. Si tous les systèmes sur lesquels je monte ma clé font ça, je risque de vite me retrouver avec un tas de déchets sur ma clé.
[^] # Re: c'est le cas
Posté par bubar🦥 (Mastodon) . Évalué à 3.
Kde Plasma ne fait pas ça, par défaut il ne lance aucune indexation sur une clef ou un disque usb. Cela peut être activé, pour certaines déjà connues ou pour toutes les nouvelles, mais cela n'est pas actif par défaut.
# Système journalisé
Posté par gUI (Mastodon) . Évalué à 4.
Au passage ajoutons le rôle d'un système de fichier journalisé. Si ton système de fichier est journalisé (par exemple ext4, mais pas ext2), alors tu ne corrompras pas ton système de fichier, même si tu écris sur la clé, même si tu arraches pendant l'écriture.
Il est conçu pour être robuste à ça. Évidemment, tu perdras éventuellement les données que tu es en train d'écrire, mais pas les autres.
Ces systèmes écrivent les modification dans un journal (d'où le nom), ensuite une opération simple et atomique consiste à dire "maintenant telle entrée du journal devient active". Soit tu es avant cette action (et du coup tu n'as perdu que les données devant être écrites) soit tu es après (et du coup tout va bien), mais tu ne peux pas te trouver au milieu (qui serait une corruption du système, et donc au pire une perte totale).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# dernier détail
Posté par cosmoff . Évalué à 1.
merci pour vos réponses.
Juste un dernier détail.
Pourquoi je peux dans certain cas ne plus pouvoir lire la totalité de ma clé USB. Car si je retire ma clé USB et que le systeme était en train d'écrire dans un fichier inode, en quoi le fait de n'avoir pas pu finir l'écriture sur un fichier inode rend ma clé USB inutilisable ?
[^] # Re: dernier détail
Posté par foobarbazz . Évalué à -1.
Probablement parce que les clés USB sont très fragiles. Elles s'usent en écrivant dessus, et c'est très courant qu'elles deviennent inutilisable au bout d'un temps relativement court.
Dans ce cas, il n'est plus possible de reformater.
[^] # Re: dernier détail
Posté par cosmoff . Évalué à 1.
tu me réponds sur la partie hardware, ce qui m’intéresse dans la question est la partie logicielle avec les méta données
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.