Performances de NTFS et grands volumes de fichiers et de répertoires

Question

Comment Windows avec NTFS fonctionne-t-il avec de grands volumes de fichiers et de répertoires ?

Existe-t-il des indications sur le nombre maximum de fichiers ou de répertoires que l'on peut placer dans un seul répertoire avant de rencontrer des problèmes de performance ou d'autres problèmes ?

Par exemple, est-il acceptable d'avoir un dossier contenant 100 000 dossiers ?

Answer 1

Voici les conseils de quelqu'un qui travaille dans un environnement où les dossiers contiennent des dizaines de millions de fichiers.

1. Un dossier stocke les informations d'indexation (liens vers les fichiers et dossiers enfants) dans un fichier d'indexation. Ce fichier devient très volumineux lorsque vous avez beaucoup d'enfants. Notez qu'il n'y a pas de distinction entre un enfant qui est un dossier et un enfant qui est un fichier. La seule différence est que le contenu de cet enfant est soit l'index du dossier de l'enfant, soit les données du fichier de l'enfant. Remarque : je simplifie quelque peu les choses, mais cela permet de faire passer le message.
2. Le fichier d'index sera fragmenté. Lorsqu'il est trop fragmenté, il est impossible d'ajouter des fichiers à ce dossier. C'est parce qu'il y a une limite au nombre de fragments autorisés. C'est une question de conception. Je l'ai confirmé auprès de Microsoft lors d'un appel d'incident de support. Ainsi, bien que la limite théorique du nombre de fichiers que vous pouvez avoir dans un dossier soit de plusieurs milliards, bonne chance lorsque vous commencerez à atteindre des dizaines de millions de fichiers, car vous vous heurterez d'abord à la limite de fragmentation.
3. Mais tout n'est pas négatif. Vous pouvez utiliser l'outil : contig.exe pour défragmenter cet index. Cela ne réduira pas la taille de l'index (qui peut atteindre plusieurs gigas pour des dizaines de millions de fichiers) mais vous pouvez réduire le nombre de fragments. Remarque : l'outil Disk Defragment ne défragmente PAS l'index du dossier. Il défragmente les données des fichiers. Seul l'outil contig.exe défragmente l'index. Pour information : vous pouvez également utiliser cet outil pour défragmenter les données d'un fichier individuel.
4. Si vous procédez à une défragmentation, n'attendez pas d'avoir atteint la limite maximale du nombre de fragments. J'ai un dossier que je ne peux pas défragmenter parce que j'ai attendu qu'il soit trop tard. Mon prochain test consiste à essayer de déplacer certains fichiers de ce dossier vers un autre dossier pour voir si je peux le défragmenter à ce moment-là. Si cela échoue, je devrais alors 1) créer un nouveau dossier. 2) déplacer un lot de fichiers vers le nouveau dossier. 3) défragmenter le nouveau dossier. répéter les étapes 2 et 3 jusqu'à ce que ce soit fait et ensuite 4) supprimer l'ancien dossier et renommer le nouveau dossier pour qu'il corresponde à l'ancien.

Pour répondre plus directement à votre question : Si vous envisagez 100 000 entrées, pas de souci. Allez vous faire voir. Si vous avez des dizaines de millions d'entrées, alors soit :

a) Prévoyez de les subdiviser en sous-dossiers (par exemple, disons que vous avez 100 millions de fichiers. Il est préférable de les stocker dans 1000 dossiers de manière à n'avoir que 100 000 fichiers par dossier plutôt que de les stocker dans un seul grand dossier. Cela créera 1000 index de dossiers au lieu d'un seul gros index qui risque davantage d'atteindre la limite du nombre maximal de fragments ou de la taille du dossier.

b) Prévoyez d'exécuter contig.exe régulièrement pour maintenir l'index de votre grand dossier défragmenté.

Ne lisez ci-dessous que si vous vous ennuyez.

La limite réelle n'est pas le nombre de fragments, mais le nombre d'enregistrements du segment de données qui stocke les pointeurs vers le fragment.

Vous disposez donc d'un segment de données qui stocke des pointeurs vers les fragments de données de l'annuaire. Les données du répertoire stockent des informations sur les sous-répertoires et les sous-fichiers que le répertoire est censé stocker. En fait, un répertoire ne "stocke" rien. Il s'agit simplement d'une fonction de suivi et de présentation qui donne à l'utilisateur l'illusion d'une hiérarchie, puisque le support de stockage lui-même est linéaire.

Answer 2

Il existe également des problèmes de performance liés à la création de noms de fichiers courts qui ralentissent les choses. Microsoft recommande de désactiver la création de noms de fichiers courts si un dossier contient plus de 300 000 fichiers [1]. Moins les 6 premiers caractères sont uniques, plus le problème se pose.

[1] Fonctionnement de NTFS de http://technet.microsoft.com , recherche "300,000"

Answer 3

Un montant de 100 000 euros devrait suffire.

J'ai vu (de manière anecdotique) des gens avoir des problèmes avec plusieurs millions de fichiers et j'ai moi-même eu des problèmes avec Explorer qui n'avait aucune idée de comment compter au-delà de 60 ou quelques milliers de fichiers, mais NTFS devrait être bon pour les volumes dont vous parlez.

Au cas où vous vous poseriez la question, la technique (et, je l'espère, la technologie) est la suivante théorique ) est le nombre maximum de fichiers : 4,294,967,295

Answer 4

Pour l'accès local, un grand nombre de répertoires/fichiers ne semble pas poser de problème. Toutefois, si vous y accédez via un réseau, les performances diminuent sensiblement après quelques centaines de fichiers (en particulier lorsque l'accès se fait à partir de machines Vista (XP à Windows Server avec/NTFS semblent fonctionner beaucoup plus rapidement à cet égard)).

Answer 5

Lorsque vous créez un dossier avec N entrées, vous créez une liste de N éléments au niveau du système de fichiers. Cette liste est une structure de données partagée à l'échelle du système. Si vous commencez ensuite à modifier cette liste en permanence en ajoutant/supprimant des entrées, je m'attends à ce qu'il y ait au moins un conflit de verrouillage sur les données partagées. Ce conflit - théoriquement - peut avoir un effet négatif sur les performances.

Pour les scénarios en lecture seule, je ne vois aucune raison de dégrader les performances des répertoires contenant un grand nombre d'entrées.