Pourquoi le système de files de Linux est-il conçu comme une seule arborescence de directorys?

Quelqu'un peut-il expliquer pourquoi Linux est conçu comme une seule arborescence de directorys?

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

    Puisque le système de files Unix est antérieur à Windows de nombreuses années, on peut reformuler la question «pourquoi Windows utilise-t-il un indicateur distinct pour chaque périphérique?

    Un système de files hiérarchique a l'avantage que n'importe quel file ou directory peut être trouvé en tant qu'enfant du directory racine. Si vous devez déplacer des données vers un nouveau périphérique ou un périphérique réseau, l'location dans le système de files peut restr le même et l'application ne verra pas la différence.

    Supposons que vous ayez un système où le operating system est statique et qu'une application a des exigences d'E / S élevées. Vous pouvez monter / usr en lecture seule et mettre / opt (si l'application vit là-bas) sur les lecteurs SSD. La hiérarchie du système de files ne change pas. Sous Windows, cela est beaucoup plus difficile, en particulier avec les applications qui insistent sur la vie 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 operating system à introduire le système de files hiérarchique tel que nous le connaissons aujourd'hui, avec des directorys pouvant contenir des directorys. Citant «Un système de files à usage général pour le stockage secondaire» par RC Daley et PG Neumann:

    La section 2 de l'article présente la structure hiérarchique des files, 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 du file peut être considérée comme une arborescence de files, dont certains sont des directorys. C'est-à-dire qu'à une exception près, chaque file (par exemple, chaque directory) se trouve directement dirigé par exactement une twig dans exactement un directory. L'exception est le directory racine, ou racine, à la racine de l'arborescence. Bien qu'il ne soit explicitement pointé dans aucun directory, la racine est implicitement pointée vers une twig fictive connue du système de files. (…)

    À tout moment, un user est considéré comme opérant dans un directory, appelé son directory de travail. Il peut accéder à un file efficacement pointé par une input dans son directory de travail en spécifiant simplement le nom de l'input. Plus d'un user peut avoir le même directory de travail en même time.

    Comme dans beaucoup d'autres aspects, Multics recherchait la flexibilité. Les users peuvent travailler dans une sous-arborescence du système de files et ignorer le rest, tout en bénéficiant des directorys pour organiser leurs files. Les directorys étaient aussi utilisés pour le contrôle d'access – l'atsortingbut READ permettait aux users de listr les files dans un directory, et l'atsortingbut EXECUTE permettait aux users d'accéder aux files de ce directory (comme beaucoup d'autres fonctionnalités).

    Multics a également suivi le principe d'avoir un seul pool de stockage. Le papier ne s'attarde pas sur cet aspect. Un seul pool de stockage correspondait bien au matériel de l'époque: il n'y avait pas de périphériques de stockage amovibles, au less aucun ne serait important pour les users. Multics disposaient d'un pool de stockage de sauvegarde distinct, mais cela était transparent pour les users.

    Unix

    Unix s'est beaucoup inspiré de Multics, mais visait à la simplicité tandis que Multics visait la flexibilité.

    Un seul système de files hiérarchique convenait bien à Unix. Comme avec Multics, les pools de stockage n'étaient généralement pas pertinents pour les users. Cependant, il y avait des périphériques amovibles, et Unix les exposait aux users, via les commands mount et umount (réservées au super-user, c'est-à-dire l'administrateur). Dans «Le système de partage de time UNIX» , Dennis Ritchie et Ken Thompson expliquent:

    Bien que la racine du système de files soit toujours stockée sur le même périphérique, il n'est pas nécessaire que l'set de la hiérarchie du système de files réside sur ce périphérique. Il y a une request de système de assembly avec deux arguments: le nom d'un file ordinaire existant et le nom d'un file spécial dont le volume de stockage associé (par exemple un package de disques) doit avoir la structure d'un système de files indépendant contenant sa propre hiérarchie de directorys . L'effet de mount consiste à faire en sorte que les references au file ordinaire précédent désignent plutôt le directory racine du système de files sur le volume amovible. En effet, mount remplace une feuille de l'tree hiérarchique (le file ordinaire) par un nouveau sous-tree (la hiérarchie stockée sur le volume amovible). Après la monture, il n'y a pratiquement aucune distinction entre les files du volume amovible et ceux du système de files permanent. Dans notre installation, par exemple, le directory racine se trouve sur une petite partition de l'un de nos disques durs, tandis que l'autre, qui contient les files de l'user, est monté par la séquence d'initialisation du système. Un système de files montable est généré en écrivant sur son file spécial correspondant. Un programme utilitaire est disponible pour créer un système de files vide, ou il suffit de copyr un système de files existant.

    Le système de files hiérarchique présente également l'avantage de concentrer la complexité de la gestion de plusieurs périphériques de stockage dans le kernel. Cela signifiait que le kernel était plus complexe, mais toutes les applications étaient plus simples. Puisque le kernel doit se préoccuper des périphériques matériels mais que la plupart des applications ne le font pas, il s'agit d'un design plus naturel.

    les windows

    Windows retrace son ascendance à deux lignées: VMS , un operating system conçu à l'origine pour le mini-ordinateur VAX , et CP / M , un operating system conçu pour les premiers micro-ordinateurs Intel.

    VMS avait un système de files hiérarchique dissortingbué, Files-11 . Dans Files-11, le path complet d'un file contient un nom de noeud, une désignation de count sur ce noeud, un nom de périphérique, un path d'access à l'arborescence, un nom de file, un type de file et un numéro de version. VMS disposait d'une puissante fonctionnalité de nom logique permettant de définir des raccourcis vers des directorys spécifiques, de sorte que les users devaient rarement se soucier de l'location «réel» d'un directory.

    CP / M a été conçu pour les ordinateurs avec 64kB de RAM et un lecteur de disquette, donc c'est parti pour la simplicité. Il n'y avait pas de directorys, mais une reference de file pourrait inclure une indication de lecteur ( A: ou B: .

    Lorsque MS-DOS 2.0 a introduit des directorys, il l'a fait avec une syntaxe compatible avec MS-DOS 1 qui lui-même a suivi CP / M. Ainsi, les paths étaient enracinés sur un lecteur avec un nom à une seule lettre. (Par ailleurs, le caractère barre oblique était utilisé dans VMS et CP / M pour démarrer les options de command line, donc un caractère différent devait être utilisé comme séparateur de directorys. sabrer).

    Windows a conservé la compatibilité avec DOS et l'approche VMS, de sorte qu'il a gardé la notion de lettres de lecteur même quand elles sont devenues less pertinentes. Aujourd'hui, sous Windows, Windows utilise des paths UNC ( développé à l'origine par Microsoft et IBM pour OS / 2 , d'ascendance apparentée). Bien que cela soit réservé aux users expérimentés (probablement en raison du poids de l'historique), Windows permet le assembly à travers les points de reparse .

    Il n'y a pas de problème de security derrière une seule arborescence de directorys.

    Les gars qui ont conçu Unix ont eu un tas d'expérience avec les systèmes d'exploitation qui ont demandé aux users de savoir quel périphérique physique contenait une ressource donnée. Puisqu'une partie du but d'un operating system est de créer une machine abstraite sur du matériel réel, ils ont pensé qu'il était beaucoup plus simple de se passer des ressources d'adressage par leur location physique et ont décidé de tout mettre dans une seule arborescence de noms.

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

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

    Un système de files correctement implémenté qui prend en charge plusieurs racines autoriserait le nommage arbitraire des volumes, comme dvdrom:/path/to/file.avi . Tels que le système permettrait de se débarrasser des problèmes d'interface user risibles qui affligent Windows. Par exemple, si vous twigz un appareil tel qu'une camera, l'interface user de l'Explorateur Windows vous fait croire qu'il y a un périphérique appelé Camera (ou autre chose) et que vous avez un path comme Computer\Camera\DCIM\... Cependant, si vous copyz et collez la version textuelle de ce path dans Explorateur, cela ne fonctionne pas car certains composants du path d'access sont une fiction d'interface user, non connue du operating system sous-jacent. Dans un système correctement implémenté avec plusieurs racines, ce serait bien: il y aurait une camera:\DCIM\... path qui est reconnu uniformément à tous les niveaux du système. De plus, si vous portez sur un vieux disque dur à partir d'un vieux PC, vous ne seriez pas coincé avec un nom de lettre de lecteur comme F: mais vous pourriez le nommer comme vous voulez, comme old-disk:

    Donc, si Unix avait plusieurs racines dans la structure du système de files, cela se ferait bien comme ça, et pas comme dans MS-DOS et Windows avec des noms de lecteur à une lettre. En d'autres termes, comparons seulement le schéma Unix à une bonne design multi-racine.

    Alors, pourquoi Unix n'a-t-il pas une implémentation multi-racines saine, en faveur d'une implémentation d'une racine unique? C'est probablement juste pour la simplicité. Les points de assembly offrent toutes les fonctionnalités nécessaires pour 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 parlant, n'importe quel graphe d'tree disjoint ("forêt") peut être joint en ajoutant un nœud racine et en faisant des morceaux disjoints ses enfants.

    De plus, il est plus flexible que les volumes ne doivent pas être au niveau racine. Comme il n'y a pas de syntaxe spéciale qui dénote le volume (c'est juste un composant de path), les points de assembly peuvent être n'importe où. Si vous apportez trois anciens disques à votre machine, vous pouvez les avoir comme /old-disk/one , /old-disk/two , etc. Vous pouvez organiser les disques comme vous le souhaitez, comme vous organisez les files et les directorys.

    Les applications peuvent être écrites en fonction des paths d'access et la validité des paths peut être maintenue lorsque les périphériques de stockage sont reconfigurés. Par exemple, les applications peuvent utiliser des paths connus comme /var/log et /var/lib . C'est à vous que /var/log et /var/lib sont sur le même volume de disque ou sur des disques séparés. Vous pouvez migrer un système vers une nouvelle topologie de stockage, tout en préservant les paths.

    Les points de assembly sont une bonne idée, c'est pourquoi Windows les a depuis depuis Windows 2000.

    Les points de assembly de volume sont robustes contre les modifications du système qui se produisent lorsque des périphériques sont ajoutés ou supprimés d'un ordinateur. Microsoft Technet

    Both * nix et Windows montent leurs lecteurs. Dans Windows, ceux-ci sont automatiquement montés dans des points de assembly 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: => partition suivante ou disque dur suivant ou lecteur CD / DVD si aucune autre partition n'est présente.

    Chacun de ces points de assembly est un directory.

    En * nix, les points de assembly sont décidés par l'user. Par exemple, j'ai une partition montée comme / , et une autre comme /home . Donc, /home est un lecteur séparé, ce serait l'équivalent de dire E: sous Windows.

    Dans les deux cas, Windows et * nix, les points de assembly sont des directorys distincts. La seule différence est que dans * nix, ces directorys distincts sont des sous-directorys de / , de C: tandis que dans Windows, chaque sharepoint assembly est monté directement sous le / , sous My Computer , disons.

    Du sharepoint vue de l'user, le principal avantage est que les montures sont complètement transparentes. Je n'ai pas besoin de savoir que le directory /home est réellement sur une partition séparée. Je peux l'utiliser comme un directory normal. Au lieu de cela, dans DOS, je devrais l'appeler explicitement par le nom du sharepoint assembly, disons E:\home

    Les disques externes sont montés à peu près de la même façon dans les deux systèmes. Dites D: pour Windows et /mnt/cdrom pour Linux. Chacun d'eux est un directory, je ne vois pas vraiment la différence. Lorsque vous mettez un CD-ROM dans votre lecteur sous Windows, le disque est monté sur D: comme dans Linux.

    Je suis d'accord avec les réponses ci-dessus, en particulier la réponse de Doug O'Neal, mais je pense qu'il leur manque un peu quelque chose, tout comme les points de assembly explicites comme MS-DOS "C" ou "A".

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

    Les namespaces … sont plus puissants quand de nouvelles sémantiques peuvent être ajoutées sans append de nouvelle syntaxe.

    Un seul espace de nom où les périphériques peuvent être montés arbitrairement permet des opérations vraiment flexibles. J'utilise régulièrement /mnt/sdb1 et /mnt/cdrom pour placer temporairement un disque ou un CD non utilisé dans le système de files global. Il n'est pas rare d'avoir des directorys de départ sur un server NFS, de sorte que peu importe la machine à laquelle vous vous connectez, vous obtenez le même $HOME partout.

    Cela se résume à ceci: avoir une syntaxe spéciale pour des choses spéciales limite définitivement ce que vous pouvez faire. Si vous ne pouvez monter qu'un disque ou un CD ou un DVD inutilisés, ou un système de files / "share" sur "E:" ou "W:", vous avez beaucoup less de flexibilité.

    C'est idiot. Windows a également un seul sharepoint hiérarchie. Mais il est caché et non standard. Comme la plupart des windows.

    Dans ce cas, c'est le concept "Poste de travail". C'est l'équivalent de root (/) dans Unix. Rappelez-vous que root est un concept qui existe dans le kernel. vous l'aimez ou pas. Tout comme les windows traitent le "Poste de travail". bien sûr, vous pouvez monter une partition à la racine sous Unix, et c'est ce que la plupart des gens font. Et beaucoup de choses vont regarder un path spécifique pour les choses (par exemple / etc /) mais vous n'êtes pas limité par cela. Par tous les moyens, montez vos disques dans / C: /. vous n'êtes pas interdit de le faire en unix.

    C: \ n'est pas une racine dans windows, c'est le sharepoint assembly d'une partition. Qui DOIT être au plus haut niveau "Poste de travail". Dans Unix, vous pouvez monter une partition sous n'importe quel autre tree. Donc linux vous pouvez avoir C: monté dans / pendant que vous avez D: monté dans /mnt/d/ … ou même monté dans / mais cela est difficile et dépend du comportement des deux filesystems lors du assembly sur un path déjà monté.

    Ainsi, vous pouvez get exactement la même chose que vous avez avec Windows en vous «forçant» à suivre les mêmes limitations imposées au hasard sur vous.

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

    Ensuite, vous devrez passer les options de assembly sur les options de démarrage. puisque vous n'aurez pas de / etc / … mais cela simule aussi les limitations que les windows imposent, comme ça ce qu'elle fait.

    La raison pour Windows ayant des lettres de lecteur remonte probablement plus loin que Microsoft et DOS. Assigner des lettres à des lecteurs amovibles était courant sur les systèmes IBM, si bien que Microsoft peut agir sur les instructions d'IBM en copiant CP / M. Et d'abord, DOS n'avait pas de directorys de toute façon.

    Lorsque MS-DOS fonctionnait sur des ordinateurs avec un ou deux disques amovibles et sans support fixe, vous n'aviez pas vraiment besoin d'un système de files avec des directorys. Avec un, ou peut-être deux disques de 180 kilo-octets, vous n'avez jamais eu assez de files pour avoir beaucoup de mal à les organiser.

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

    En fait, Linux est basé sur Unix (ou Unix, voir la discussion ) et Unix vient de l'environnement mainframe, où l'utilisation de plusieurs périphériques était assez évidente. Le assembly de périphériques dans une seule arborescence de directorys vous offre une flexibilité maximale et ne limite pas le nombre de périphériques auxquels le operating system peut accéder.

    De l'autre côté, les lettres DOS pour les lecteurs sont une bonne design pour un PC avec 1 ou 2 stations de disquette et un seul lecteur de disque. Big floppy 5,25 'est toujours A :, le petit 3,5' est toujours B:, et le lecteur de disque est toujours C :. Vous savez toujours si vous copyz un file sur la disquette ou quelque part sur le disque. Vous n'avez pas besoin de flexibilité si vous ne pouvez pas connecter physiquement plus de 2 lecteurs de disquettes et 2 (ou 4) disques durs.

    La design DOS était plus conviviale, tandis que la design Unix est conviviale pour l'administrateur. Maintenant, les lettres de lecteur sont un fardeau pour Windows, les users countnt plus sur l'ouverture automatique de la window de l'explorateur avec un contenu de lecteur amovible que de connaître sa lettre … Ubuntu fait de même, en fait.

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

    "Unit Letters" ne sont que quelque chose à retenir facilement les paths, les disques et les partitions.

    Les paths ARC définissent le path d'un file dans Windows (mais ils ne sont visibles par l'user 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 fait assignés de manière spécifique à des lettres / noms, comme / dev / sdb1. Mais ils peuvent être montés n'importe où à partir de la structure simple / racine
    2. La raison la plus courante pour laquelle les gens (y compris moi-même dans le passé) avaient des disques séparés dans Windows était d'avoir un endroit où conserver les documents, la musique, les programmes, etc. échec du système de files, il y avait toujours access à ces files. Je n'ai pas ce problème sous linux – le système de files est beaucoup plus fiable, le operating system ne casse pas sauf par une action directe ou une erreur de ma part (ooh! Un repo de saignement, essayons ça! sont plus simples. Et, dans les rares cas, j'ai dû réinstaller, puisque tout le logiciel était disponible via des repos ou des ppa que j'ai ajouté (et je pouvais facilement copyr ma maison dir avec un disque live), à ​​partir de zéro et de revenir à l'endroit où je n'a duré que quelques heures par rapport aux jours de search de nouveaux installateurs et / ou d'anciennes keys cd lors de la restauration de mes programmes sous Windows.

    Si vous regardez en arrière dans l'histoire, vous pouvez également voir qu'Unix a démarré à l'époque des systèmes de bandes 8 pistes pour les systèmes de données audio et 8 pistes IBM (8 pistes / 8 bits pour datatables, une pour la parité). Techniquement pareil.

    À ce moment-là, les informations sur l'location des files étaient stockées dans certaines parties de l'information sur la bande et définies en avant et en arrière lorsque vous lisez datatables de la bande (comme un file avec la position de départ et la signature de fin); cela explique aussi pourquoi vous n'aviez pas un seul FAT au début du disque, vous en avez plusieurs pour accélérer la search. Et si vous avez plusieurs lecteurs, ils sont liés à l'intérieur de / dev et via l'adresse du file que vous avez déplacé entre les périphériques.

    I believe you could have the view that it started simply earlier and that the decision behind MS Dos area (CP/M) and later Windows NT is simply related to VM mainframe drive letters instead of a single point of entry because at the time it looked more modern, data amounts of today didn't exist and they didn't think that you would eventually end up having not enough drive letters or that it would be over cluttered.

    9-Track-Drive and Drive Letter assignment