Pourquoi le système de fichiers Linux est-il conçu comme une arborescence de répertoires unique?

Quelqu'un peut-il expliquer pourquoi Linux est conçu comme une arborescence de répertoires unique?

Alors que dans Windows, nous pouvons avoir plusieurs lecteurs comme C:\, et D:\, il existe une seule racine sous Unix. Une raison spécifique là-bas?

Étant donné que le système de fichiers Unix est antérieur à Windows depuis de nombreuses années, on peut reformuler la question: "Pourquoi Windows utilise-t-il un code distinct pour chaque périphérique?".

Un système de fichiers hiérarchique présente l'avantage de pouvoir trouver n'importe quel fichier ou répertoire en tant qu'enfant du répertoire racine. Si vous devez déplacer des données vers un nouveau périphérique ou un périphérique réseau, l'emplacement dans le système de fichiers peut rester le même et l'application ne verra pas la différence.

Supposons que vous avez un système où le système d'exploitation est statique et qu'il existe une application avec des exigences d'E / S élevées. Vous pouvez monter / usr en lecture seule et mettre / opt (si l'application y réside) sur des disques SSD. La hiérarchie du système de fichiers ne change pas. C’est beaucoup plus difficile sous Windows, en particulier avec des applications qui insistent pour vivre sous C: \ Program Files \

C'est en partie pour des raisons historiques et en partie parce que cela a plus de sens de cette façon.

Multics

Multics a été le premier système d'exploitation à introduire le système de fichiers hiérarchique tel que nous le connaissons aujourd'hui, avec des répertoires pouvant contenir des répertoires. Citant «Un système de fichiers polyvalent pour le stockage secondaire» de RC Daley et PG Neumann:

La section 2 du document présente la structure hiérarchique des fichiers, ce qui permet une utilisation flexible du système. Cette structure contient des capacités suffisantes pour assurer la polyvalence. (…)

Pour faciliter la compréhension, la structure de fichier peut être considérée comme une arborescence de fichiers, dont certains sont des répertoires. Autrement dit, à une exception près, chaque fichier (par exemple, chaque répertoire) se trouve directement pointé par exactement une branche dans exactement un répertoire. L'exception est le répertoire racine, ou root, à la racine de l'arborescence. Bien qu'il ne soit explicitement désigné à partir d'aucun répertoire, la racine est implicitement désignée par une branche fictive connue du système de fichiers. (…)

À tout moment, un utilisateur est considéré comme fonctionnant dans un répertoire, appelé son répertoire de travail. Il peut accéder à un fichier effectivement désigné par une entrée de son répertoire de travail en spécifiant simplement le nom de l'entrée. Plusieurs utilisateurs peuvent avoir le même répertoire de travail à la fois.

Comme dans de nombreux autres aspects, Multics recherchait la flexibilité. Les utilisateurs peuvent travailler dans une sous-arborescence du système de fichiers et ignorer le reste, tout en bénéficiant des répertoires pour organiser leurs fichiers. Les répertoires étaient également utilisés pour le contrôle d'accès - l'attribut READ permettait aux utilisateurs de répertorier les fichiers d'un répertoire et l'attribut EXECUTE permettait aux utilisateurs d'accéder aux fichiers de ce répertoire (comme beaucoup d'autres fonctionnalités, conservées sous Unix).

Multics a également suivi le principe d’un seul pool de stockage. Le papier ne s'attarde pas sur cet aspect. Un seul pool de stockage correspond bien au matériel de l'époque: il n'y avait aucun périphérique de stockage amovible, du moins aucun dont les utilisateurs auraient intérêt à se soucier. Multics disposait d'un pool de stockage de sauvegarde distinct, mais celui-ci était transparent pour les utilisateurs.

Unix

Unix s’inspirait beaucoup de Multics, mais visait la simplicité alors que Multics visait la flexibilité.

Un système de fichiers hiérarchique unique convenait parfaitement à Unix. Comme avec Multics, les pools de stockage n'étaient généralement pas pertinents pour les utilisateurs. Cependant, il y avait des périphériques amovibles, et Unix les a exposés aux utilisateurs, via les commandes mountet umount(réservées au «super-utilisateur», c'est-à-dire l'administrateur). Dans «Le système de partage du temps UNIX» , Dennis Ritchie et Ken Thompson expliquent:

Bien que la racine du système de fichiers soit toujours stockée sur le même périphérique, il n'est pas nécessaire que toute la hiérarchie du système de fichiers réside sur ce périphérique. Il existe une demande de système de montage avec deux arguments: le nom d'un fichier ordinaire existant et le nom d'un fichier spécial auquel le volume de stockage associé (par exemple, un pack de disques) doit avoir la structure d'un système de fichiers indépendant contenant sa propre hiérarchie de répertoires. . L'effet de la fonction de montage fait que les références au fichier ordinaire précédent se réfèrent plutôt au répertoire racine du système de fichiers sur le volume amovible. En effet, mount remplace une feuille de l'arborescence de la hiérarchie (le fichier ordinaire) par une nouvelle sous-arborescence (la hiérarchie stockée sur le volume amovible). Après le montage, il n’existe pratiquement aucune distinction entre les fichiers du volume amovible et ceux du système de fichiers permanent. Dans notre installation, par exemple, le répertoire racine réside sur une petite partition de l’un de nos lecteurs de disque, tandis que l’autre lecteur, qui contient les fichiers de l’utilisateur, est monté par la séquence d’initialisation du système. Un système de fichiers montable est généré en écrivant sur le fichier spécial correspondant. Un utilitaire est disponible pour créer un système de fichiers vide ou vous pouvez simplement copier un système de fichiers existant.

Le système de fichiers hiérarchique présente également l’avantage de concentrer la complexité de la gestion de plusieurs périphériques de stockage dans le noyau. Cela signifiait que le noyau était plus complexe, mais que toutes les applications étaient donc plus simples. Comme le noyau doit se soucier des périphériques matériels, mais que la plupart des applications ne le font pas, cette conception est plus naturelle.

les fenêtres

Windows retrace ses origines dans deux lignées: VMS , un système d'exploitation conçu à l'origine pour le mini-ordinateur VAX , et CP / M , un système d'exploitation conçu pour les premiers micro-ordinateurs Intel.

VMS disposait d'un système de fichiers hiérarchique distribué, Files-11 . Dans Fichiers-11, le chemin d'accès complet à un fichier contient un nom de nœud, une désignation de compte sur ce nœud, un nom de périphérique, un chemin d'accès à l'arborescence de répertoires, un nom de fichier, un type de fichier et un numéro de version. VMS possédait une puissante fonctionnalité de nom logique permettant de définir des raccourcis vers des répertoires spécifiques. Les utilisateurs devaient donc rarement se préoccuper de l'emplacement «réel» d'un répertoire.

CP / M a été conçu pour les ordinateurs dotés de 64 Ko de RAM et d’un lecteur de disquette. La simplicité s’imposait. Il n'y avait pas de répertoires, mais une référence de fichier pouvait inclure une indication de lecteur ( A:ou B:).

Lorsque MS-DOS 2.0 a introduit les répertoires, il l'a fait avec une syntaxe compatible avec MS-DOS 1 qui suivait elle-même CP / M. Ainsi, les chemins ont été enracinés sur un lecteur avec un nom composé d'une seule lettre. (De plus, la barre oblique /était utilisée dans VMS et CP / M pour démarrer les options de ligne de commande. Il fallait donc utiliser un autre caractère comme séparateur de répertoire. C’est pourquoi DOS et Windows utilisent la barre oblique inversée, bien que certains composants internes prennent également en charge les barres obliques. )

Windows conservait la compatibilité avec les approches DOS et VMS et conservait donc la notion de lettres de lecteur, même lorsqu'elles devenaient moins pertinentes. Aujourd'hui, sous le capot, Windows utilise des chemins UNC ( développés à l'origine par Microsoft et IBM pour OS / 2 , d'ascendance associée). Bien que cela soit réservé aux utilisateurs expérimentés (probablement en raison du poids de l'historique), Windows autorise le montage via des points d'analyse .

Il n'y a pas de problème de sécurité derrière une arborescence de répertoires unique.

Les concepteurs de Unix possédaient une grande expérience des systèmes d’exploitation, qui obligeaient les utilisateurs à savoir quel périphérique physique contenait une ressource donnée. Étant donné qu'une partie du but d'un système d'exploitation est de créer une machine abstraite au-dessus d'un matériel réel, ils ont trouvé beaucoup plus simple de se passer des ressources d'adressage par leur emplacement physique et ont décidé de tout mettre dans une seule arborescence de noms.

Ceci n'est qu'une partie du génie derrière la conception d'Unix .

Notez que les noms de lettre de lecteur de MS-DOS qui persistent dans Windows moderne constituent ici un fil rouge. Les noms de lettre de lecteur ne sont pas la meilleure représentation d'une structure de système de fichiers ayant plusieurs racines. Ils sont une implémentation d'un tel système.

Un système de fichiers correctement implémenté qui prend en charge plusieurs racines autoriserait l'attribution de noms arbitraires aux volumes, comme dvdrom:/path/to/file.avi. Un tel système permettrait de se débarrasser des problèmes d’interface utilisateur risibles qui minent Windows. Par exemple, si vous connectez un périphérique tel qu'un appareil photo, l'interface utilisateur de Windows Explorer vous fait croire qu'il existe un périphérique appelé Appareil photo (ou autre) et que vous avez un chemin similaire à Computer\Camera\DCIM\.... Toutefois, si vous coupez et collez la version textuelle de ce chemin dans Explorer, cela ne fonctionne pas, car certains composants du chemin d'accès constituent une fiction de l'interface utilisateur, inconnue du système d'exploitation sous-jacent. Dans un système correctement mis en place avec plusieurs racines, cela irait: il y aurait unecamera:\DCIM\...chemin qui est reconnu uniformément à tous les niveaux du système. En outre, si vous portiez un ancien disque dur à partir d’un ancien ordinateur, vous ne seriez pas bloqué avec un nom de lettre de lecteur du type F:, mais vous pourriez plutôt le nommer comme vous le souhaitez old-disk:.

Donc, si Unix avait plusieurs racines dans la structure du système de fichiers, cela se ferait de la manière la plus appropriée, et non comme dans MS-DOS et Windows avec des noms de lecteur à une lettre. En d'autres termes, comparons uniquement le schéma Unix à un bon design multi-racine.

Alors, pourquoi Unix n’a-t-il pas une implémentation saine à plusieurs racines, en faveur d’une implémentation saine à une racine? C'est probablement juste pour la simplicité. Les points de montage fournissent toutes les fonctionnalités permettant d'accéder aux volumes via des noms. Il n'est pas nécessaire d'étendre l'espace de noms avec une syntaxe de préfixe supplémentaire.

Mathématiquement, tout graphe d’arbre disjoint ("forêt") peut être joint en ajoutant un nœud racine et en transformant les morceaux disjoints en ses enfants.

De plus, il est plus flexible que les volumes ne soient pas obligatoirement au niveau racine. Comme il n’existe pas de syntaxe spéciale indiquant le volume (c’est juste un composant de chemin), les points de montage peuvent être n’importe où. Si vous apportez trois anciens disques sur votre ordinateur, vous pouvez les avoir comme /old-disk/one, /old-disk/two, etc. Vous pouvez organiser des disques comme vous le voulez, la façon dont vous organisez des fichiers et des répertoires.

Il est possible d’écrire des applications qui dépendent de chemins, et la validité de ces chemins peut être conservée lors de la reconfiguration des périphériques de stockage. Par exemple, les applications peuvent utiliser des chemins d'accès connus tels que /var/loget /var/lib. Il est à vous si /var/loget /var/libsont sur le même volume de disque ou sur les séparés. Vous pouvez migrer un système vers une nouvelle topologie de stockage tout en préservant les chemins.

Les points de montage sont une bonne idée, c'est pourquoi Windows les utilise depuis Windows 2000 environ.

Les points de montage de volume sont robustes face aux modifications du système qui surviennent lorsque des périphériques sont ajoutés ou supprimés d'un ordinateur. Microsoft Technet

* Nix et Windows montent leurs lecteurs. Sous Windows, ceux-ci sont automatiquement montés dans des points de montage qui, par défaut, sont classés par ordre alphabétique croissant. Ces valeurs par défaut sont:

• A:et B:=> disquettes
• C: => première partition du premier disque dur
• D: => prochaine partition ou prochain disque dur ou lecteur de CD / DVD si aucune autre partition n'est présente.

Chacun de ces points de montage est un répertoire.

Dans * nix, les points de montage sont déterminés par l'utilisateur. Par exemple, une partition est montée en tant que /et une autre en tant que /home. Donc, /homeest un lecteur séparé, ce serait l'équivalent de dire E:sous Windows.

Dans les deux cas, Windows et * nix, les points de montage sont des répertoires distincts. La seule différence est que dans * nix, ces répertoires distincts sont des sous-répertoires de /, C:alors que dans Windows, chaque point de montage est monté directement sous le /sous, My Computerpar exemple.

Du point de vue de l'utilisateur, le principal avantage est que les montages sont complètement transparents. Je n'ai pas besoin de savoir que le répertoire /homeest en fait sur une partition séparée. Je peux juste l'utiliser comme un répertoire normal. Au lieu de cela, dans DOS, je devrais l'appeler explicitement par le nom du point de montage, disonsE:\home

Les disques externes sont montés à peu près de la même manière dans les deux systèmes. Dis D:pour Windows et /mnt/cdrompour Linux. Chacun de ceux-ci est un répertoire, je ne vois pas vraiment la différence. Lorsque vous insérez un CD-ROM dans votre lecteur sous Windows, le disque est monté D:comme dans Linux.

Je suis d'accord avec les réponses ci-dessus, en particulier celle de Doug O'Neal, mais je pense qu'elles manquent toutes un petit quelque chose, tout comme les points de montage de périphériques explicites tels que "C:" ou "A:" de MS-DOS.

Rob Pike a écrit The Hideous Name sur la syntaxe des noms, mais Russ Cox l'a résumé :

Les espaces de noms ... sont plus puissants lorsque de nouvelles sémantiques peuvent être ajoutées sans ajouter de nouvelle syntaxe.

Un seul espace de noms sur lequel les périphériques peuvent être montés à volonté permet des opérations vraiment flexibles. J'utilise régulièrement /mnt/sdb1et /mnt/cdromplace temporairement un disque ou un CD non utilisé dans le système de fichiers global. Il n'est pas rare de posséder des répertoires de départ sur un serveur NFS, de sorte que peu importe la machine à laquelle vous vous connectez, vous obtenez la même chose $HOMEpartout.

Cela revient à ceci: avoir une syntaxe spéciale pour des choses spéciales impose des limites précises à ce que vous pouvez faire. Si vous ne pouvez monter qu'un disque ou un CD ou un DVD inutilisé, ou un système de fichiers réseau / "partager" sur "E:" ou "W:" ou autre, vous avez beaucoup moins de flexibilité.

C'est idiot. Windows a également un seul point de hiérarchie. Mais c'est caché et non standard. Comme la plupart des choses Windows.

Dans ce cas, il s’agit du concept "Poste de travail". C'est l'équivalent de root (/) sous Unix. Rappelez-vous que la racine est un concept qui existe dans le noyau. tu l'aimes ou pas. Tout comme Windows traite le "Mon ordinateur". bien sûr, vous pouvez monter une partition sur root sous Unix, et c'est ce que font la plupart des gens. Et beaucoup de choses regarderont un chemin spécifique (par exemple / etc /) mais vous n’êtes pas limité par cela. Bien sûr, montez vos lecteurs dans / C: /. vous n'êtes pas interdit de le faire sous unix.

C: \ n’est pas une racine dans Windows, c’est le point de montage d’une partition. Ce qui DOIT être au plus haut niveau "Mon ordinateur". Sous UNIX, vous pouvez monter une partition sous n’importe quel arbre. Vous pouvez donc installer C: dans Linux et /D: dans /mnt/d/... ou même également, /mais cela est délicat et dépend de la façon dont les deux systèmes de fichiers se comportent lors du montage sur un chemin déjà monté.

Vous pouvez donc obtenir exactement la même chose que vous avez avec Windows en vous "obligeant" à respecter les mêmes limites que Windows vous impose de manière aléatoire.

/ (treat this as "My Computer")
/c/ (mount your first data partition here)
/d/ (mount your second data partition here)

Ensuite, vous devrez passer dans les options de montage sur les options de démarrage. puisque vous n’avez pas de / etc / ... mais que cela simule aussi les limitations que Windows impose, comme ce que ça fait.

La raison pour laquelle Windows a des lettres de lecteur remonte probablement plus loin que Microsoft et DOS. L'affectation de lettres à des lecteurs amovibles était courante sur les systèmes IBM. Microsoft a donc peut-être simplement suivi les instructions d'IBM en copiant CP / M. Et au début, de toute façon, DOS n’avait pas de répertoires.

Lorsque MS-DOS s'exécutait sur des ordinateurs avec un ou deux disques amovibles et aucun support fixe, vous n'aviez pas vraiment besoin d'un système de fichiers avec des répertoires. Avec un, ou peut-être deux, disques de 180 kilo-octets, vous n’avez jamais eu assez de fichiers pour avoir beaucoup de difficulté à les organiser.

https://en.wikipedia.org/wiki/Drive_letter_assignment

En réalité, Linux est basé sur Unix (ou Unix, voir la discussion ) et Unix provient d'un environnement mainframe, où l'utilisation de plusieurs périphériques était assez évidente. Le montage de périphériques dans une arborescence de répertoires unique vous offre une flexibilité maximale et ne limite pas le nombre de périphériques auxquels le système d'exploitation peut accéder.

De l’autre côté, les lettres DOS pour les lecteurs sont bien conçues pour un PC avec 1 ou 2 stations de disquette et un seul lecteur de disque. La grande disquette 5,25 'est toujours A :, la petite 3,5' est toujours B: et le lecteur est toujours C :. Vous savez toujours si vous copiez un fichier sur la disquette ou quelque part sur le disque. Vous n'avez besoin d'aucune flexibilité si vous ne pouvez pas connecter physiquement plus de 2 lecteurs de disquettes et 2 (ou 4) disques durs.

La conception DOS était plus conviviale pour les utilisateurs finaux, tandis que la conception Unix était conviviale pour les administrateurs. Maintenant, les lettres de lecteur sont un fardeau pour Windows, les utilisateurs dépendent davantage de l'ouverture automatique de la fenêtre de l'explorateur avec le contenu du lecteur amovible que de la connaissance de sa lettre ... Ubuntu en fait de même.

Ce n'est pas vrai, en fait. Windows utilise un autre schéma de chemins (enfin, pas le même)

Les "lettres d'unité" ne sont que des éléments à retenir, tels que chemins, disques et partitions.

Les chemins ARC définissent le chemin d'un fichier dans Windows (mais ils ne sont visibles à l'utilisateur qu'au démarrage):

http://support.microsoft.com/kb/102873

https://serverfault.com/questions/5910/how-do-i-determine-the-arc-path-for-a-particular-drive-letter-in-windows

Dans Windows NT, il n'y a pas de relation entre les disques, les partitions et les lettres d'unité: vous pouvez "mettre" un volume entier dans un dossier (par exemple: c: \ myseconddisk pourrait être un disque physique entier!)

Deux choses que je voudrais souligner -

1. Les disques durs sous Linux sont en quelque sorte des lettres / noms assignés, comme / dev / sdb1. Mais ils peuvent être montés n’importe où pour être atteints à partir de la structure unique / racine
2. La raison la plus courante pour les personnes (y compris moi-même dans le passé) avaient des lecteurs distincts dans Windows était de pouvoir conserver des documents, de la musique, des programmes, etc. défaillance du système de fichiers, il y avait toujours un accès à ces fichiers. Je n'ai pas ce problème sous Linux - le système de fichiers est beaucoup plus fiable, le système d'exploitation ne se casse pas, sauf par une action directe ou une erreur de ma part (ouh! Un repo à la fine pointe, essayons ça!), Et des mises à jour sont loin plus simples. Et, dans les rares cas où j'ai eu à réinstaller, puisque tous les logiciels étaient disponibles via des pensions ou des PPA que j'ai ajoutés (et je pouvais facilement copier mon répertoire personnel avec un disque live),

Si vous parcourez l'historique, vous pouvez également constater qu'Unix a démarré à l'époque des systèmes de bande à 8 pistes pour les systèmes de données audio et IBM à 9 pistes (8 pistes / 8 bits pour les données, une pour la parité). Techniquement très identique.

À ce moment, les informations sur l'emplacement des fichiers étaient stockées dans des parties de l'information sur la bande et définies avant et arrière lorsque vous lisiez des données sur la bande (comme un fichier, avec position de départ et signature de fin); cela explique également pourquoi vous n'aviez pas un seul FAT au début du lecteur, mais plusieurs pour accélérer la recherche. Et si vous aviez plusieurs lecteurs, ils étaient liés à l'intérieur de / dev et via l'adresse du fichier que vous avez déplacé entre les périphériques.

Je pense que vous pourriez penser que cela a commencé tout simplement plus tôt et que la décision derrière la zone MS Dos (CP / M) et plus tard Windows NT est simplement liée aux lettres de lecteur de l'ordinateur central VM au lieu d'un point d'entrée unique, car à l'époque plus modernes, les données actuelles n’existaient pas et ils ne pensaient pas que vous finiriez par ne plus avoir suffisamment de lettres de lecteur ou qu’il serait encombré.

Affectation 9-Track-Drive et lettre de lecteur