Windows 10 a changé de stratégie sur le retrait des périphériques de stockage USB
Le 09 avril 2019 à 10h23
1 min
Logiciel
Logiciel
Depuis de nombreuses années, la stratégie appliquée par défaut est celle des meilleures performances. Dans les grandes lignes, le cache d’écriture des fichiers est placé sur le périphérique pour améliorer les performances.
Ce mode est assorti malheureusement d’une contrainte. Pour s’assurer qu’aucune corruption de données n’a lieu, il faut aller chercher la petite icône de clé USB à droite de la barre de tâches pour « retirer le périphérique en toute sécurité ».
Un fonctionnement jugé sans doute archaïque par Microsoft. Le comportement a donc changé dans la version 1809 de Windows 10, sans qu’il soit repéré par grand monde jusqu’à récemment. La documentation a d’ailleurs été mise à jour le 4 avril.
Si vous avez la dernière évolution majeure de Windows 10, la stratégie par défaut est désormais « Suppression rapide ». Microsoft avertit qu’une petite baisse de performances peut être constatée, mais le changement est en fait invisible avec des périphériques récents en USB 3.0, la hausse des performances matérielles compensant depuis longtemps l’absence d’optimisation logicielle.
Le 09 avril 2019 à 10h23
Commentaires (25)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 09/04/2019 à 08h51
« Suppression rapide » ça veut dire qu’on peut virer à chaud sans faire le retirer un périphérique en toute sécurité c’est bien ça svp ?
Le 09/04/2019 à 08h53
C’est ce qu’ils disent, et j’avais bien eu l’impression de ne plus voir l’icone, c’est quand même plus pratique :P
Le 09/04/2019 à 08h54
sauf erreur de ma part il me semble que le cache n’était activé que sur les disques durs/ssd usb et non sur les clefs usb. Une exception la clef usb sandisk extreme pro est reconnue comme un ssd et activais le cache il me semble. En tout cas j’ai toujours débranché mes clefs usb sans passer par l’outil et je n’ai jamais eu de corruption de données, je le fait que pour les disques durs/ssd usb.
Le 09/04/2019 à 09h02
Deux questions :
Le 09/04/2019 à 09h03
doublon, à supprimer
Le 09/04/2019 à 09h31
Si tu as toujours regardé le voyant du périphérique qui clignote avant de le retirer, c’est normal que ça se soit bien passé. J’ai dû avoir un fichier foiré une seule fois.
Ce qui arrivait souvent, c’est que tu copies un fichier, la fenêtre de copie se ferme, mais en fait, il n’a pas fini d’écrire sur le support externe, si tu es trop pressé (c’est pas plus de 15s de retard d’écriture en général), tu peux corrompre les données.
Le problème est plus si un logiciel tient vraiment un fichier ouvert sur le support externe, là on a un risque, mais la tendance est plus souvent à la sauvegarde périodique plutôt qu’à garder les fichiers ouverts (ce qui n’empêche pas d’avoir un verrou d’écriture dessus).
Le 09/04/2019 à 09h31
Je ne suis pas sur que ça soit le cas même pour les disques durs USB. Je n’ai jamais vu le mode performance activé par défaut. Mais je suis peut-etre passé a coté depuis windows 10…
Le 09/04/2019 à 09h47
D’après la documentation linkée dans l’article, oui.
Le 09/04/2019 à 09h51
Le 09/04/2019 à 10h51
Des semaines que je me demande pourquoi ce comportement a changé sur ma machine. Sans dec…
Le 09/04/2019 à 10h54
chez Microsoft personne ne s’est dit un jour qu’un petit bouton “ejecter” serait pas mal à côté du volume dans explorer
Le 09/04/2019 à 11h10
Sinon, tu peux faire clic-droit, puis “Éjecter” (l’entrée apparaît pour une clé USB en tout cas)
" />
Le 09/04/2019 à 11h23
Je faisais un clic droit sur le E:\ –> Ejecter, dans l’explorateur. C’était rapide.
Ils ont intérêt à être sûr de leur coup, y’a un risque de perte de données quand même.
Le 09/04/2019 à 11h27
Le 09/04/2019 à 11h53
Le mode “quick removal” existe depuis Windows 7.
" />
L’activer par défaut, pourquoi pas mais il faut que ca fonctionne à 100%… ce qui n’a jamais été le cas jusqu’a présent sur windows 7, 8 et 10.
On en a fait des essais pour essayer de sécuriser les données écrites (forcer un flush, attente 2-5 secondes avant de retirer la clé, …), mais rien n’est aussi fiable que la fonction dédiée “eject/safe to remove”… et bien sur, c’est une fonction qui n’est pas facilemement accessible depuis les API de windows
Le 09/04/2019 à 12h14
Après plus de 20 ans le dé-branchage à chaud de l’usb est enfin effectif, merci microsoft.
Pour des raison de vieux con qui a connu l’obligation d’éteindre la machine pour ajouter/supprimer un périphérique je n’ai jamais utiliser cette saloperie d’icône que j’avais considéré comme une régression anachronique lors de son apparition sous windows 7.
Le 09/04/2019 à 12h21
Le 09/04/2019 à 13h14
pas pour les disques durs
" />
Le 09/04/2019 à 13h39
Le 09/04/2019 à 13h54
Le 09/04/2019 à 14h05
Le 09/04/2019 à 14h30
Après, théoriquement, si tu touches pas à la clef ou au disque dur pendant plusieurs minutes, le cache aura été écrit et c’est pas trop risqué de l’enlever. Typiquement, si ton HDD externe s’est mis en veille, c’est censé être safe ^^
Le 09/04/2019 à 14h32
Je n’ai jamais respecté la consigne.
Bon débarras
Le 09/04/2019 à 17h36
Le 12/04/2019 à 05h02
Dans le second lien de la news : “You can change the policy setting for each external device, and the policy that you set remains in effect if you disconnect the device and then connect it again to the same computer port.”
C’est moi, ou cela peut amener a des comportements du genre un coup ça marche, un coup ça marche pas. Juste parce que la clé ou le disque n’ont pas été branché dans le même port, glup!
Ou alors j’ai mal compris la notion de port, ici ?
Ces histoires de cache en écriture, ça a toujours été compliqué. Mais il me semblait avoir lu que pour le cache du périphérique, par exemple un disque dur, il y avait un composant (genre, tout petit condensateur) qui permettait de vider le cache même en cas de coupure de l’alimentation électrique.
Ça ne garanti pas l’intégrité du file system ou des fichiers (il y a d’autres choses pour ça, en tout cas sur les FS journalisés). Mais au moins l’intégrité et l’atomicité des écritures sur le disque.
Qu’il n’y ai pas un bloc de données partiellement écrit. Une écriture considéré comme terminée par le système, alors qu’en fait, pas du tout.
On m’aurai mentis (ou plus probablement, j’aurai mal compris ?)