Mauvaises performances NTFS

Pourquoi les performances NTFS sont-elles si nulles comparées, par exemple, à Linux / ext3? Le plus souvent, je vois cela lors de la vérification des (grandes) arborescences sources de Subversion. Le paiement prend environ 10 à 15 minutes sur NTFS, tandis que le paiement correspondant sur Linux (sur un matériel presque identique) prend un ordre de grandeur plus rapidement (1 à 1,5 minute).

Peut-être que cela est spécifique à la gestion de nombreux petits fichiers et que NTFS est meilleur quand il s'agit de gros fichiers, mais pourquoi devrait-il en être ainsi? L'amélioration des performances NTFS pour les petits fichiers ne serait-elle pas extrêmement bénéfique pour les performances de Windows en général?

EDIT: Il ne s'agit pas d'une question inflammatoire "NTFS suce par rapport à ext3"; Je suis vraiment intéressé par les raisons pour lesquelles NTFS fonctionne mal dans certains cas. Est-ce simplement une mauvaise conception (dont je doute), ou y a-t-il d'autres problèmes qui entrent en jeu?

NTFS a ce qu'on appelle une table de fichiers maîtres . Cela semble vraiment cool lorsque vous lisez à ce sujet.

Vous pouvez voir qu'ext3 fonctionne correctement jusqu'à environ 95% d'utilisation du disque, tandis que l'existence du MFT signifie que NTFS ne veut pas vraiment que vous utilisiez plus de 90% de votre disque. Mais je suppose que ce n'est pas votre problème et que votre problème concerne les nombreuses opérations sur de nombreux petits fichiers.

L'une des différences ici est ce qui se passe lorsque vous créez un petit fichier. Si un fichier est plus petit qu'une taille de bloc, il n'est pas écrit dans son propre bloc mais est plutôt stocké dans le MFT. C'est bien si le fichier reste exactement tel qu'il était lors de sa création. En pratique cependant, cela signifie que lorsque svn touche un fichier pour le créer, puis l'ajoute à ce fichier, le supprime ou le modifie simplement par pas assez pour le déplacer vers son propre bloc, l'opération est assez lente. De plus, la lecture de nombreux petits fichiers met un peu l'accent sur la MFT où ils résident tous, avec des multiples par bloc. Pourquoi ferait-il ça? C'est éviter de manière préventive la fragmentation et utiliser plus de blocs plus efficacement, et en général c'est une bonne chose.

En ext2 et 3 en revanche, les blocs de fichiers pour chaque fichier sont stockés à côté de l'emplacement des métadonnées du répertoire pour le répertoire dans lequel ils se trouvent (si possible, si votre disque n'est pas fragmenté et que vous disposez d'environ 20% d'espace libre). Cela signifie que lorsque svn ouvre des répertoires, un certain nombre de blocs sont mis en cache essentiellement gratuitement dans ce cache de 16 Mo sur votre disque, puis à nouveau dans le cache du noyau. Ces fichiers peuvent inclure le fichier .svn et les fichiers de révision pour votre dernière mise à jour. C'est pratique car ce sont probablement certains des fichiers que svn examine ensuite. NTFS ne peut pas faire cela, bien que de grandes parties du MFT doivent être mises en cache dans le système, ce ne sont peut-être pas les parties que vous voudrez ensuite.

Eh bien, votre problème particulier est que

1. Subversion elle-même vient du monde UNIX, la version Windows suppose donc des caractéristiques de performances similaires.
2. Les performances NTFS ne sont vraiment pas excellentes avec des millions de petits fichiers.

Ce que vous voyez est simplement un artefact de quelque chose conçu pour un système d'exploitation particulier avec des hypothèses de performances sur ces systèmes d'exploitation. Cela se décompose généralement mal lorsqu'il est appliqué à d'autres systèmes. D'autres exemples seraient le forking contre le filetage. Sous UNIX, la manière traditionnelle de mettre en parallèle quelque chose consiste simplement à générer un autre processus. Sous Windows, où les processus prennent au moins cinq fois plus de temps pour démarrer, c'est une très mauvaise idée.

En général, vous ne pouvez pas simplement accepter des artefacts d'un système d'exploitation particulier sur un autre avec une architecture très différente. N'oubliez pas non plus que NTFS possède de nombreuses fonctionnalités de système de fichiers qui étaient absentes dans les systèmes de fichiers UNIX largement utilisés à ce stade, telles que la journalisation et les listes de contrôle d'accès. Ces choses ont un prix.

Un jour, quand j'ai beaucoup de temps libre, je prévoyais d'écrire un module de système de fichiers SVN qui tire parti des fonctionnalités que vous avez sur NTFS, telles que le support des transactions (devrait éliminer le "problème touchant des millions de petits fichiers") et des données alternatives streams (devrait éliminer la nécessité d'un .svnrépertoire séparé ). Ce serait une bonne chose, mais je doute que les développeurs SVN parviennent à mettre en œuvre de telles choses dans un avenir prévisible.

Note latérale: Une seule mise à jour sur un grand référentiel SVN que j'utilise a pris environ 250 000 opérations sur les fichiers. Une petite voix me dit que c'est vraiment beaucoup pour 24 fichiers qui ont changé ...

Voici les informations de Microsoft sur le fonctionnement de NTFS. Cela peut être exagéré pour ce que vous recherchez, mais son étude peut éclairer les scénarios avec lesquels NTFS a des problèmes.