Point de jonction NTFS du disque dur au SSD, cela entraînera-t-il un goulot d'étranglement des performances? (relocalisation de jeux Steam)

Un point de jonction NTFS entre les disques durs peut-il provoquer un goulot d'étranglement? Ou la jonction sera-t-elle mise en cache en mémoire?

Plus précisément, je souhaite installer Steam sur un disque dur magnétique. Cela signifie que tous les jeux y seront installés. Pour bénéficier de mon SSD, je vais pointer les jeux auxquels je joue activement du répertoire Steam sur le disque dur vers le SSD.

Je me demandais si cela causerait un problème de performances. Chaque fois que le jeu accède à un fichier, doit-il lire le disque dur, lire le point de jonction, résoudre le nouveau chemin sur le SSD, puis obtenir le vrai fichier? Ou est-ce que le système d'exploitation mettra en cache cette réorientation de sorte que la pénalité de performance n'est frappée que la première fois?

Merci!

— ddtemplar
source

La définition d'un point de jonction est directement stockée dans l'entrée MFT responsable. Comme le MFT est mis en cache en mémoire, je ne m'attendrais pas à ce que le disque dur soit accessible lorsque vous travaillez avec le répertoire lié.

— Gene

Merci! Je ne m'en inquiéterai pas trop à ce moment-là, sauf si je commence à remarquer des ralentissements étranges.

— ddtemplar

Même si le disque dur devait être accédé pour lire le point de jonction, il est minuscule - la lecture serait terminée presque immédiatement, et ne devrait se produire qu'une seule fois car elle serait mise en cache.

— Adambean

Remarque: Si vous installez l'application Steam sur le SSD, vous pouvez toujours changer l'emplacement d'installation du jeu à l'intérieur de Steam sans jonction.

— cybernard

Non, ce ne sera probablement pas un goulot d'étranglement. Des frais généraux sont associés aux jonctions NTFS, mais dans votre scénario, ils devraient être négligeables.

Vous pouvez vous débarrasser des frais généraux en déplaçant physiquement les données vers le SSD et en n'utilisant pas du tout de jonctions (ce qui semble être la préoccupation principale de votre question pour moi), mais je doute que vous puissiez mesurer la différence.

Où les jonctions sont-elles stockées et mises en cache?

Les jonctions sont des types de points d'analyse qui sont tous stockés dans le $Extend\$Reparse métafichier (un autre métafichier plus célèbre est le $MFT).

Lorsqu'un fichier ou un répertoire est associé à un point d'analyse, NTFS crée un attribut nommé $Reparsepour le point d'analyse. Cet attribut stocke le code d'analyse et les données. Pour que NTFS puisse facilement localiser tous les points d'analyse sur un volume, un fichier de métadonnées nommé \$Extend\$Reparsestocke les entrées qui connectent le fichier de points d'analyse et les numéros d'entrée de répertoire MFT à leurs codes de points d'analyse associés. NTFS trie les entrées par numéro d'entrée MFT dans l' $Rindex.

source: Inside Win2K NTFS, partie 1 par Mark Russinovich

Diagramme de réparation

source: Inside Win2K NTFS, partie 1 par Mark Russinovich

Il a été dit que les jonctions sont stockées dans MFT et que MFT est mis en cache. Eh bien maintenant, lorsque nous savons où les jonctions sont stockées, j'aurais besoin d'une source crédible pour prendre en charge la revendication de mise en cache; que je n'ai pas pu trouver.

Donc je ne sais pas, mais je ne pense pas que ça compte.

Existe-t-il un scénario documenté où la jonction inter-disques a diminué les performances?

Oui, ARF a rencontré un problème comme celui-ci. Il évaluait la suppression par lots de petits fichiers, et lorsque l'opération a été effectuée à travers la jonction, le facteur limitant n'était plus IO (comme prévu) mais le CPU. Cette référence a également été discutée en détail sur GitHub .

— Vlastimil Ovčáčík
source