Des réponses intéressantes jusqu'à présent. Je vais partager ma propre perspective peu commune à ce sujet : J'ai travaillé sur un système de fichiers de journalisation (pour les systèmes UNIX) qui a été commercialisé avec succès peu de temps avant le lancement de Windows NT 3.1. J'ai commencé à travailler sur Windows NT 3.1 alors qu'il était encore en version bêta et j'ai appris beaucoup de choses sur le fonctionnement interne de Windows, notamment en ce qui concerne les systèmes de fichiers. J'ai rencontré l'actuel responsable du développement de NTFS en 1996 (avant qu'il ne soit chez Microsoft, en fait) lorsqu'il a suivi mon cours "Developing File Systems for Windows" (avec 52 autres personnes). Je l'ai revu le mois dernier et, comme d'habitude, nous avons fini par parler de systèmes de fichiers.
Les systèmes de fichiers ont tendance à avoir une très longue durée de vie en tant que logiciel parce qu'ils traitent de la gestion de données persistantes. Ils ont de fortes exigences de fiabilité : lorsque votre navigateur web manque de mémoire et se plante, vous redémarrez votre navigateur web et le problème disparaît, mais lorsque votre système de fichiers manque de mémoire et se plante, vous redémarrez votre ordinateur et vous découvrez quelles données ont été perdues. Les problèmes peuvent être persistants et récurrents.
La conception de NTFS était à la pointe du développement des systèmes de fichiers à l'époque. Ils avaient tenté de construire leurs systèmes de fichiers à la manière d'un micro-noyau, de sorte que les systèmes de fichiers s'exécutaient dans des processus séparés bien qu'ils aient finalement abandonné cette approche parce qu'elle n'était pas suffisamment performante sur les systèmes dont ils disposaient à l'époque. Les vestiges de cette approche demeurent aujourd'hui (ils ont des routines Fsp ou "processus de système de fichiers" pour gérer les opérations de système de fichiers en file d'attente). Dave Cutler, l'architecte de Windows NT, était un partisan de longue date des micro-noyaux (il est co-auteur d'un article SOSP de 1973 qui décrit un micro-noyau avant que ce soit la terminologie courante). NTFS utilisait un journal transactionnel d'écriture en avance pour assurer la résilience face aux pannes du système, probablement basé sur le travail du système de fichiers Cedar plusieurs années auparavant. Il incorporait des ACL à grain fin (mais c'était aussi le cas du système de fichiers sur lequel je travaillais - en effet, lorsque j'ai vu leur implémentation d'ACL, j'étais tout à fait à l'aise avec elle car il semblait que nous avions tous deux suivi exactement les mêmes brouillons de sécurité POSIX.)
Il avait de multiples unités disparates de données de fichiers au sein d'un seul fichier ("flux"), quelque chose que nous avions implémenté mais en utilisant un nom différent et avec de plus grandes restrictions. Il avait des attributs étendus (provenant d'OS/2). C'était un système de fichiers insensible à la casse (requis pour la conformité POSIX.1). Il utilisait des extents pour décrire les fichiers (similaire au système de fichiers de Veritas à l'époque). Une décision originale consistait à dupliquer les informations d'attributs de fichiers dans leurs répertoires, ce qui rendait l'énumération des répertoires avec des attributs très rapide.
Internellement, il utilisait (et utilise toujours) une table d'index plat assez standard (puisque la plupart des systèmes de fichiers hiérarchiques sont construits au-dessus d'une table plate, la hiérarchie étant construite logiquement au-dessus de l'espace de noms plat).
Il supportait les fichiers "inline" (les données sont donc stockées dans l'enregistrement MFT, qui est l'équivalent de l'inode sur le disque). Il utilisait nativement des noms UNICODE 16 bits pour presque tout (la seule exception étant les noms d'attributs étendus, qui sont des chaînes ASCII 8 bits.)
Au fil du temps, ils ont ajouté des fonctionnalités : prise en charge de la compression, prise en charge du cryptage, ACL partagées (il y a donc une table d'ACL plutôt que de les copier dans chaque fichier séparé, ce qui permet de gagner de l'espace.)
Le système de fichiers NTFS fournit une interface de stockage transactionnel aux programmes d'application, de sorte que vous pouvez faire des choses comme "renommer cet ensemble de fichiers de manière atomique" - et cela n'a pas nécessité qu'ils changent le format sur le disque pour le faire. Le registre Windows, qui est une base de données de configuration, dépend des transactions NTFS pour mettre en œuvre sa propre interface transactionnelle (notez qu'il n'est pas obligé de l'être, c'était juste plus facile étant donné la disponibilité de ces transactions). Bien sûr, vous pouvez construire votre propre moniteur transactionnel, mais lorsque le système de fichiers le fournit, vous pouvez également scripter vos opérations de système de fichiers pour qu'elles soient transactionnelles.
À la fin des années 1980 et au début des années 1990, la défragmentation était généralement effectuée par des programmes externes, et non par le système de fichiers. Le faire dans le système de fichiers revient à déplacer une fonctionnalité complexe du mode utilisateur au mode noyau, ce qui est généralement déconseillé car nous essayons de limiter la complexité au niveau du noyau (puisque les erreurs au niveau du noyau ont des conséquences plus graves qu'au niveau utilisateur...). De même, je ne voudrais pas non plus que mon système de fichiers fasse directement l'accélération du chargement des programmes - laissez-le dans une application et utilisez le système de fichiers pour enregistrer les informations pertinentes. Demandez au chargeur de programme d'utiliser ces informations pour accélérer le chargement.
Dans Windows Vista, NTFS a introduit des opérations de réparation en ligne du système de fichiers (j'ai gloussé lorsque j'ai entendu quelqu'un à FAST 2018 prétendre que leur système de fichiers était le premier à le faire, plus de 10 ans après que l'équipe NTFS l'ait mis en œuvre.) Au fil du temps, ils ont encore amélioré cette capacité à réparer des dommages mineurs en ligne, et leurs outils de récupération hors ligne, les rares fois où vous devez les exécuter, sont devenus adeptes de la réparation des dommages.
Aujourd'hui, dans Windows 10, NTFS prend en charge le stockage DAX, qui est certainement à la pointe de la technologie (je ne peux même pas obtenir facilement une mémoire de classe de stockage pour mes propres recherches sur les systèmes de fichiers), mais il continue de fournir un comportement solide comme le roc. Il est activement maintenu, donc je sais que si je signale un bogue, il sera corrigé (et j'ai signalé et fait corriger des bogues dans NTFS plusieurs fois au cours des années.)
La dernière fois que j'ai regardé, Windows n'a pas de cache de recherche de nom de répertoire (DNLC), ce qui ralentit les performances ouvertes. Dans mes propres travaux sur les systèmes de fichiers sous Windows dans le passé, j'utilisais un cache de recherche rapide pour cela - un cache à une seule entrée par CPU démontrait un taux de réussite de ~80% à l'époque en raison du décalage entre l'API native Win32 et NT (l'API native est dominée par les opérations de handle, l'API Win32 est dominée par les opérations de nom...). Ce n'est pas tant un problème de système de fichiers qu'un problème de système d'exploitation et au fil des années, le nombre d'API basées sur les noms au niveau natif ont augmenté et le nombre d'API basées sur les handles au niveau Win32 ont également augmenté.
La performance des systèmes de fichiers est souvent une fonction de l'implémentation, et non de la structure sur le disque. Les systèmes de fichiers conçus pour les lecteurs de disques doivent être accordés/modifiés pour fonctionner avec les SSD (par exemple). De même, des choses comme le cache de page deviennent un frein aux performances lorsque vous accédez directement à la mémoire.
Pour une conception vieille de 28 ans, je dirais que NTFS a plutôt bien résisté. Pouvons-nous faire mieux maintenant en utilisant du matériel moderne, des progrès dans notre compréhension des défaillances, et l'augmentation de 10.000x de la taille de notre stockage et de nos mémoires ? Je serais plutôt surpris que nous ne le puissions pas. Mais il faudra dix ans ou plus avant que le système de fichiers que nous construisons aujourd'hui pour le matériel actuel soit "prêt pour le prime time". Donc, si vous voulez créer un nouveau système de fichiers, ne prévoyez pas le matériel d'aujourd'hui. Planifiez pour le matériel qui sera disponible dans 10 ans.
La ligne de fond : NTFS reste un excellent exemple de la conception des systèmes de fichiers de journalisation des années 1980, en équilibrant les fonctionnalités et les performances.
Les systèmes de fichiers de journalisation ne sont pas seulement des systèmes de fichiers.