Pourquoi y a-t-il tant de conceptions de systèmes de fichiers concurrentes? [fermé]

Juste une question rapide, mais pourquoi tant de systèmes de fichiers sont-ils encore en concurrence et utilisés aujourd'hui? (ntfs, fat32, ext3 (ffs), etc.)

Il semble que les concepteurs de systèmes de fichiers pourraient s'entendre sur les meilleurs aspects de chaque type de système et mettre en œuvre un "meilleur" système de fichiers, non? Juste une pensée, puisque ces systèmes de fichiers existent depuis un certain temps maintenant, et il devrait être au moins quelque peu apparent lesquels ont de bonnes qualités par rapport aux autres, et nous pourrions simplement combiner le bon dans chacun et créer un système ultime qui est beaucoup mieux

Réfléchissons un instant aux détails, en utilisant les exemples que vous avez cités:

• ntfs - Propriétaire de Microsoft. Toute personne qui n'est pas Microsoft ne peut pas utiliser cela, donc devrait utiliser / créer quelque chose de différent. Maintenant, si vous êtes Microsoft, vous souhaitez l'utiliser sur FAT en raison des problèmes du prochain point.

• fat32 - Pas assez moderne. La taille maximale du fichier est de 4 Go. La recherche d'entrée dans l'annuaire est O (n). La table d'allocation est une liste liée, plutôt que quelque chose de plus efficace comme un bitmap d'allocation (où il est vraiment rapide de trouver de l'espace libre contigu). Ne prend pas en charge les autorisations. Ne prend pas en charge les liens durs ou les liens symboliques. Ne prend pas en charge la journalisation.

• ext3 - Il s'agissait d'une extension d'ext2 principalement pour prendre en charge la journalisation.

Il semble donc qu'il y ait plusieurs raisons:

1. Un système de fichiers antérieur manque quelque chose. Dans le cas de FAT, il manque beaucoup: à la fois en termes de (1) fonctionnalités et (2) de performances. Dans le cas d'ext2, il n'avait pas de mises à jour journalisées, donc la récupération après un crash a pris plus de temps.

2. Un système de fichiers existant ferait probablement l'affaire, mais ce n'est pas le vôtre. (par exemple. NTFS si vous n'êtes pas Microsoft). Dans ce cas, vous n'avez pas vraiment d'autre choix que de proposer le vôtre.

Réponse courte: une taille unique ne convient pas à tous.

Il y a des compromis. Par exemple, si vous voulez un FS journalisé, vous payez (efficacité, complexité, etc.), mais vous en tirez quelque chose. Certains ne ressentent pas le besoin d'un FS journalisé et ne veulent pas payer pour cela, certains le font. Idem avec les autres "fonctionnalités" du FS.

Il ne peut jamais y avoir un «meilleur» de quoi que ce soit, car il y a tellement d'opinions sur ce qu'est le «meilleur». La décision est spécifique aux besoins et aux limites de l'utilisateur. Les conceptions sont toujours basées sur leur capacité à s'adapter aux contraintes.

Un téléphone mobile de base doit stocker quelques centaines de contacts, l'historique des messages texte et quelques petites applications. Son système de fichiers doit-il prendre en charge une structure de répertoires hiérarchique sur des disques multi-téraoctets dans une configuration RAID? Y a-t-il suffisamment de RAM sur l'appareil pour exécuter un tel système de fichiers? Le système de fichiers a-t-il besoin d'ACL complexes? Probablement pas - pour toutes ces questions - donc un système de fichiers simple et gourmand en ressources suffirait.

Les entreprises développeront également différents produits afin de conserver un avantage concurrentiel. Par exemple, Apple vante la capacité de son système de fichiers HFS + de suivre les fichiers qui ont été modifiés récemment afin que les sauvegardes soient rapides. D'un autre côté, les pilotes pour un système de fichiers de disquette (FAT) peuvent tenir dans seulement quelques Ko de mémoire.

Trop dépend de ce que vous souhaitez optimiser.

Considérez FAT pendant un moment: sa prise en charge des noms de fichiers longs est kludgy (pour le dire bien), et la recherche dans les fichiers d'un répertoire est linéaire, donc elle ralentit très rapidement si un répertoire contient beaucoup de fichiers. En même temps, il a un strict minimum de métadonnées pour que la vitesse d'écriture brute soit très bonne, et comme il est si simple dans l'ensemble, le code à implémenter peut être assez petit.

Quelque chose comme ext2 ou ext3 ajoute de nombreuses fonctionnalités et capacités qui sont tout simplement absentes de FAT. La recherche de fichiers est également beaucoup plus rapide. Dans le même temps, la vitesse d'écriture brute est probablement un peu plus lente et le code pour implémenter le système de fichiers est sans aucun doute beaucoup plus volumineux.

Juste une question rapide, mais pourquoi tant de systèmes de fichiers sont-ils encore en concurrence et utilisés aujourd'hui? (ntfs, fat32, ext3 (ffs), etc.)

Il semble que les concepteurs de systèmes de fichiers pourraient s'entendre sur les meilleurs aspects de chaque type de système et mettre en œuvre un "meilleur" système de fichiers, non?

Supposons qu'il n'y ait pas eu de compromis, et les concepteurs de systèmes de fichiers ont mis en œuvre un "meilleur" système de fichiers, exempt de soucis de brevets, et publié en double licence BSD / GPL afin qu'il soit acceptable pour MS et Debian. Qu'est-ce qui vous fait penser que les autres systèmes de fichiers disparaîtraient du jour au lendemain?

Je ne pense pas que quiconque ait utilisé FAT32 sur un nouveau disque dur pendant 10 ans, mais il persiste toujours en tant que norme de facto pour le formatage des clés USB, des cartes SD, etc. Les fabricants d'appareils photo et de téléphones portables ont essayé et testé le firmware pour l'utiliser. Les amateurs d'Arduino ont des bibliothèques stables pour l'utiliser. Ils vont tous avoir besoin de grandes incitations pour changer.

Et puis vous avez les problèmes de compatibilité descendante avec les anciens systèmes d'exploitation (en particulier Windows, dont les utilisateurs ne voudront pas installer de nouveaux pilotes de système de fichiers).

Comme c'est souvent le cas dans le calcul, la réponse est (a) en raison de circonstances historiques et de la nécessité de maintenir la compatibilité descendante et (b) parce que certaines méthodes sont mieux adaptées à certaines tâches que d'autres.

Sur (a) vous devez vous rappeler que le "disque Winchester" - je suis à peu près assez vieux pour me souvenir qu'ils s'appelaient ainsi - (ce que le reste du monde appelle un "disque dur") n'existe que depuis environ la moitié temps de l'informatique électronique et même alors, il n'a pas été accessible à la plupart des utilisateurs pour aussi longtemps pour des raisons de coût. Le système de fichiers FAT fonctionnait bien sur les disquettes et également sur les petits disques durs d'origine car il était raisonnablement efficace et nécessitait une faible surcharge. Une fois qu'il a commencé à être utilisé - et son utilisation s'est largement répandue parce qu'il est simple à mettre en œuvre - les fabricants ne pouvaient pas dire à leurs utilisateurs que leurs anciennes données étaient soudainement invalides.

De même, pour les utilisateurs de Linux, par exemple, un pilote NTFS stable était long à venir, donc garder les périphériques formatés en FAT signifiait qu'ils pouvaient être lus et écrits sur plusieurs systèmes.

Sur (b) - pensez aux différences entre un système qui, par exemple, stocke des milliards d'enregistrements de bases de données textuelles et un autre qui stocke des fichiers multimédias de longueur DVD. Pour la base de données, chaque enregistrement peut être très petit - peut-être seulement 30 ou 40 octets et certainement un système de fichiers qui a alloué un `` segment '' entier (comme vous voulez le définir) de disque est susceptible de gaspiller de l'espace disque. Ce n'est pas le cas avec les DVD - des «segments» plus gros (dans des limites raisonnables, évidemment) sont susceptibles d'être très efficaces en termes d'espace.

Ainsi, différents systèmes de fichiers sont conçus à des fins différentes.

Encore un autre exemple de pourquoi il ne peut jamais y avoir de système de fichiers parfait pour tout le monde: les disques durs et les SSD ont des caractéristiques d'accès en lecture / écriture très différentes. Un système de fichiers optimisé pour SSD fonctionnerait probablement mieux en fragmentant les fichiers comme des fous mais avec chaque fragment la taille de page du SSD lui-même; cela fonctionnerait terriblement sur un disque dur. Un système de fichiers optimisé pour les disques durs essaie de garder les fichiers aussi peu fragmentés que possible et place même les fichiers fréquemment utilisés dans la zone "chaude" de la partie extérieure à rotation plus rapide du plateau; ces caractéristiques n'aideraient en rien les vitesses de lecture des disques SSD et imposent une énorme charge sur la façon dont elles sont écrites.

Je pense qu'il manque un fait très important. La plupart du temps, les programmeurs ont tendance à penser que leur façon de faire quelque chose est supérieure à toutes les autres et donc ils regardent une conception de système de fichiers et trouvent des problèmes et des solutions qui semblent être plus généraux, élégants, rapides, corrects. Et si ce sentiment est suffisamment fort, ils sont libres de créer leur propre système de fichiers.

Cela dépend de la concurrence, de la fragmentation, de la confiance et j'espère à la fin de meilleures solutions et plus d'options pour choisir une solution correspondante pour vous.

Voici un autre exemple concret de la raison pour laquelle vous auriez besoin d'un système de fichiers distinct ou étendre les fonctionnalités d'un FS existant.

1. Supposons que vous êtes un fournisseur de bases de données et que vous souhaitez réduire la complexité de la gestion de la répartition / mise en miroir des données pour améliorer les E / S. Vous ressentirez le besoin d'étendre les fonctionnalités des systèmes de fichiers de base comme Oracle l'a fait avec ASM (Automated Storage Manager) qui est comme un gestionnaire de volumes logiques.

Dans votre liste, vous mentionnez un ancien système de fichiers utilisé car un meilleur n'est pas disponible mais il est rapide.

Il existe d'autres systèmes de fichiers. J'ai entendu que le système de fichiers Google est principalement destiné à la duplication / redondance rapide si un disque dur ou un serveur tombe en panne. Je me souviens avoir entendu parler d'un autre système de fichiers conçu pour de nombreux petits fichiers et destiné à être utilisé sur un système pour de nombreuses requêtes sur de petits fichiers (vignettes).

Essentiellement, ils ont des objectifs différents et peuvent être appropriés par rapport à l'open source.

Je pense que ZFS (utilisé par Solaris dans le système Sun [maintenant Oracle]) est LA solution pour le système de fichiers.

Malheureusement, Oracle ferme OpenSolaris pour l'outil de découverte et le teste.

ZFS est open source, certains Linux essaient de l'intégrer, regardez dans Wikipedia pour plus d'informations.