C’est le responsable Ned Pyle en personne qui a confirmé le souci dans les forums officiels. Il se produit bien une dégradation de performances lorsque l’on copie de gros fichiers depuis un serveur distant vers une machine équipée de Windows 11 2022.
La chute peut atteindre 40 % tout de même, de quoi largement impacter les utilisateurs concernés, notamment les personnes se servant de SMB. Le problème ne survient que sur les copies impliquant des fichiers de plusieurs Go au moins. Il n’est pas censé se produire localement, mais en fonction du scénario d’utilisation, une chute pourrait être constatée.
L’éditeur promet un correctif pour bientôt. En attendant, les personnes concernées peuvent utiliser robocopy ou xcopy avec le paramètre /J pour contourner le problème.
Commentaires (40)
#1
J’imagine bien l’allure de l’utilisateur après qu’il a été impacté par une chute de débit, il se retrouve avec une queue de 10 000 km.
#2
Bah… l’utilisateur de Windows a l’habitude qu’on annonce 2 minutes au début du transfert qui se transforment en 5 minutes 10 minutes plus tard.
Un “gros ficher” pour moi c’est pas plusieurs Go en 2022.
Bref, la portée du problème n’est même pas clairement identifiée.
#3
#4
Ha ? J’ignorais que Windows avait déjà été performant pour copier des gros fichiers.
#5
obligatory xkcd
https://xkcd.com/612/
#5.1
#6
excellent
#7
Avec des disques principaux entre 250Go et 2To et les transferts actuels des SSD (même SATA), c’est plus 1ou 2Go que 500Mo en 2022. Après, ça touche ceux qui ont un NAS, mais aussi en entreprise (je suis sur W11-2H22) où on se sert encore beaucoup de partages réseaux en SMB.
#7.1
Un simple fichier vidéo (une utilisation courante pour les particuliers) c’est déjà plusieurs Go pour une définition basique, plusieurs dizaines si on cherche la qualité.
En entreprise, j’imagine le cauchemar de récupérer un export de BDD dont la volumétrie est bien plus importante, par exemple.
Mon seul poste sous Windows est mon PC de boulot, pour des raisons de compatibilité logicielle. Plus je lis des trucs sur W11, plus je me dis que la suggestion de Windows Update de migrer vers cette version va attendre encore longtemps.
#8
#9
C’est pas le seul problème sur cette win 11 2022, il y a le comeback du print nightmare et d’autres : https://www.neowin.net/news/windows-11-22h2-has-issues-with-remote-desktop-microsoft-investigating/
#10
Tu peux faire des copies en “local” (= sur le même PC) en passant par le redirecteur réseau, et donc être confronté au problème.
#11
Ils sont quand même toujours aussi énormes chez MS… Capable d’avoir des bugs / problèmes de performance sur de la copie de fichier.
Excellent.
#12
Dans ce cas oui. A lire ton premier message, on a tendance à penser que tu comptais encore en Mo, vu que rien n’était précisé.
#12.1
Je comprends la confusion. Au contraire, les usages aujourd’hui font que le gigaoctet est devenu “l’unité de base”.
#13
D’un autre coté ça permet à plein d’éditeurs tiers de vivre, sans les “légers” soucis de copie de fichiers de Windows (ou les fonctionnalités manquantes genre ordonnancement, copies multiples, etc …) les Ultracopier, terraCopy, SuperCopier, etc … n’existeraient pas
Sans les “spécialistes en ergonomie” de chez MS pas non plus d’OpenShell (je rêve de pouvoir un jour choisir mon gestionnaire de fenêtre comme sous Linux pour ne plus avoir à subir les lubies de leurs “designers”)
Je pense qu’on doit pouvoir décliner ça quasi à l’infini en prenant tous les points sur lesquels Windows est perfectible (pour rester poli)
#14
C’est parcequ’ils doivent scanner tout fichier copié pour voir si c’est pas du contenu pédopornographique? … oups, trop tôt… je la refais dans 6 mois…
#15
xcopy ? Il me semble que ça fait au moins 10 ans que Microsoft a annoncé que cette commande était obsolète et qu’il fallait lui privilégier robocopy, bien plus robuste.
#16
Mwais, enfin, robocopy est lui-même devenu obsolète le jour où rsync est sorti…
#17
???
tu parles de rsync du monde linux ? Celui qui nécessite d’avoir un service TCP qui tourne sur la machine distante ?
#18
J’imagine que tu parles du daemon rsyncd ? Ça fait des dizaines d’années qu’il est obsolète. rsync marche très bien avec ssh.
#19
Que ce soit rsyncd ou sshd, ca reste “un service TCP qui tourne sur la machine distante” et qui est absolument nécessaire pour réaliser le transfert des données.
Ca me parait abusif de dire que rsync a rendu robocopy obsolète car les prérequis et les modes de fonctionnement ne sont pas du tout les mêmes. Ce sont deux solutions au même problème, mais pas vraiment faites pour les mêmes usages.
#19.1
Je me demande comment fait Robocopy pour copier à distance sans aucun service TCP. Du quantique, peut-être.
#20
Robocopy ne copie pas spécialement “à distance” ou “en local”: Il copie entre deux répertoires accessibles par l’utilisateur. Les moyens mis en œuvre pour le transfert de fichiers entre ces répertoires ne sont pas gérés par Robocopy mais par le système d’exploitation. Si ca requiert un transfert par le réseau c’est l’OS qui s’en occupe, pas robocopy.
Contrairement à rsync qui a historiquement été conçu pour la synchronisation via le réseau. D’où son nom “remote sync”.
#21
il y aurait des bugs avec le RDP sur la 21H2, et un bug dans la version entreprise
Microsoft nous propose tout un festival de bugs sur cette version Windows 11
Je suis pas près de migrer.
#21.1
j’espère que cet OS sera plus stable en 2025 … mais bon vu le bordel y aura peut être Windows 12
#22
Entre ssh sur le port 22 et SMB sur le port 445, les deux écoutent sur le réseau. La distinction “c’est l’OS qui s’en occupe” est complètement artificielle. SMB et ssh sont tous les deux des services systèmes. Et niveau sécurité, je fais nettement plus confiance à ssh qu’à SMB. Mais alors, vraiment plus. Il ne doit pas y en avoir beaucoup, des machines qui ont SMB accessible depuis l’extérieur du firewall (je veux dire : des cas où c’est volontaire et où le sysadmin est serein).
Malgré son nom, rsync est utilisé très couramment pour des synchronisations locales. Tu peux aussi l’utiliser pour synchroniser à distance en utilisant un montage NFS, pour mimer le fonctionnement de robocopy si ça te chante, ça marche aussi. Et là, pas besoin de ssh ni de rsyncd. Et NFS “fait partie” de l’OS, si c’est un aspect important pour toi.
#23
rsync peut copier des fichiers en local tout comme robocopy (qui fait du local seulement me semble, en tous cas des lettres de lecteur genre C: ou autre).
rsync n’a même pas besoin de ssh pour de la simple copie/synchronisation.
rsync peut remplacer “cp”, avec en prime un affichagede la progression du transfert (selon les options utilisées).
#24
ça marche aussi pour les copies locales… pas besoin de daemon sur une machine distante.
Pour ma part, j’utilise rsync depuis plus de deux décennies pour faire des copies massives - et incrémentales - de données, que ce soit de volume à volume ou entre machines (via ssh, de manière sé&curisée)
#25
Vu qu’il parlait de service TCP, j’imaginait qu’il parlait uniquement de la copie distante. Parce qu’en local, oui, ça fait 20 ans que j’utilise rsync pour de la synchro locale.
#25.1
C’est un peu rassurant de savoir que pour accéder à une machine’il faut un machin quelconque qui tourne sur le PC distant, qu’il soit un daemon, une application lancée pour l’occasion, ou un service de l’OS, non ?
Et quand tout le reste a raté, il reste encore ce bon vieux ftp, ça marche à tous les coups.
Ou alors…
https://www.youtube.com/watch?v=LbYlmhKtcwE
#26
Un truc dommage, c’est qu’on ne peut plus faire de SSH sans chiffrement du flux, tu pouvais choisir le “cipher” comme “none” quand tu était sur une infra de confiance, je m’en servais pour les “scp” et les “rsync” entre mes machines, surtout à une époque où certains de mes CPU ne suivaient pas le 100 Mb/s en chiffrement (ou à peine avec grosse charge CPU), je te parle d’il y a une quinzaine d’années avec un CPU Via en particulier.
#26.1
Bof.
Comme tu le dis, il y aune quinzaine d’année, certaines machines pouvaient avoir du mal.
Être sur une infra de confiance est quelque chose dont il est difficile d’être sûr, donc autant chiffrer.
Et ça évite que l’on puisse être non chiffré par erreur.
#27
comme je l’ai écrit, rsync et robocopy sont équivalents en terme de fonctionnalité = de services rendus à l’utilisateur. Ca inclut la copie locale/locale, locale/remote, etc.
Mais leur mode de fonctionnement est différent.
Robocopy n’établit pas de connexions réseaux. Par exemple on ne peut pas spécifier un nom d’utilisateur/password à utiliser pour se connecter à un hôte distant. Soit l’OS est capable d’atteindre le chemin spécifié et la copie commence, soit l’OS n’est pas capable d’atteindre le chemin spécifié et la copie échoue.
Au contraire de rsync qui va établir la connexion avec le protocole et les informations spécifiées, par exemple:
rsync -e ssh -az /src user@host:/dest/rsync serait équivalent à robocopy si rsync faisait seulement du local et qu’on doive créer un point de montage samba pour faire une copie distante.
#27.1
Mauvais exemple. Rsync n’établit pas de communication, il demande à ssh de le faire pour lui. Et ssh, c’est autant dans le système que SMB.
#28
TU AS RAISON, T’ES TROP FORT
#29
Non puisqu’il faut mettre une option en ligne de commande.
En plus de transmettre presque toujours en interne, je ne transmets par forcément des choses sensibles (et surtout, qui va intercepter mon rsync, sérieusement).
Et c’est du gâchis de CPU que de faire chiffrer le trafic, je trouve. Pour le principe en partie, déjà.
#30
Les CPU ont des instructions spécifiques qui s’appuient sur une accélération matérielle depuis un moment.
#31
Je pense que ton commentaire m’était plus particulièrement destiné.
Effectivement, j’ai testé la commande openssl avec et sans l’accélération AES (avec une option en ligne de commande, de mémoire), on gagne un facteur 5, pas mal déjà. On est au-delà du Go/s pour le CPU grand public que j’ai testé.
Pour OpenSSH et scp en revanche, je n’ai pas regardé ce qu’il en était et si c’était facile à mettre en oeuvre.