Warum ist das Linux-Dateisystem als ein einziger Verzeichnisbaum konzipiert?

Kann jemand erklären, warum Linux als einzelner Verzeichnisbaum konzipiert ist?

Während in Windows mehrere Laufwerke vorhanden sein C:\können D:\, gibt es in Unix nur ein einziges Stammverzeichnis. Gibt es einen bestimmten Grund?

Da das Unix-Dateisystem viele Jahre älter ist als Windows, kann man die Frage "Warum verwendet Windows für jedes Gerät einen eigenen Bezeichner?" Umformulieren.

Ein hierarchisches Dateisystem hat den Vorteil, dass jede Datei oder jedes Verzeichnis als untergeordnetes Element des Stammverzeichnisses gefunden werden kann. Wenn Sie Daten auf ein neues Gerät oder ein Netzwerkgerät verschieben müssen, kann der Speicherort im Dateisystem gleich bleiben und die Anwendung erkennt den Unterschied nicht.

Angenommen, Sie haben ein System mit statischem Betriebssystem und einer Anwendung mit hohen E / A-Anforderungen. Sie können / usr schreibgeschützt einhängen und / opt (sofern die App dort vorhanden ist) auf SSD-Laufwerke setzen. Die Dateisystemhierarchie ändert sich nicht. Unter Windows ist dies viel schwieriger, insbesondere bei Anwendungen, die darauf bestehen, unter C: \ Programme \ zu leben.

Dies ist teils aus historischen Gründen, teils weil es auf diese Weise sinnvoller ist.

Multics

Multics war das erste Betriebssystem, das das heutige hierarchische Dateisystem mit Verzeichnissen eingeführt hat, die Verzeichnisse enthalten können. Unter Bezugnahme auf „Ein universelles Dateisystem für die Sekundärspeicherung“ von RC Daley und PG Neumann:

In Abschnitt 2 des Papiers wird die hierarchische Struktur der Dateien vorgestellt, die eine flexible Nutzung des Systems ermöglicht. Diese Struktur enthält ausreichende Fähigkeiten, um die Vielseitigkeit sicherzustellen. (…)

Zum leichteren Verständnis kann die Dateistruktur als ein Baum von Dateien angesehen werden, von denen einige Verzeichnisse sind. Das heißt, mit einer Ausnahme wird jede Datei (z. B. jedes Verzeichnis) von genau einem Zweig in genau einem Verzeichnis direkt angesprochen. Die Ausnahme ist das Stammverzeichnis (root) im Stammverzeichnis des Baums. Obwohl von keinem Verzeichnis explizit darauf verwiesen wird, wird implizit auf die Wurzel durch einen fiktiven Zweig verwiesen, der dem Dateisystem bekannt ist. (…)

Zu jeder Zeit wird davon ausgegangen, dass ein Benutzer in einem Verzeichnis arbeitet, das als sein Arbeitsverzeichnis bezeichnet wird. Er kann auf eine Datei zugreifen, auf die durch einen Eintrag in seinem Arbeitsverzeichnis effektiv verwiesen wird, indem er einfach den Eintragsnamen angibt. Es kann sein, dass mehrere Benutzer gleichzeitig dasselbe Arbeitsverzeichnis haben.

Wie in vielen anderen Aspekten suchte Multics nach Flexibilität. Benutzer können in einem Teilbaum des Dateisystems arbeiten und den Rest ignorieren und trotzdem von Verzeichnissen profitieren, um ihre Dateien zu organisieren. Verzeichnisse wurden auch für die Zugriffskontrolle verwendet - das READ-Attribut ermöglichte es Benutzern, die Dateien in einem Verzeichnis aufzulisten, und das EXECUTE-Attribut ermöglichte es Benutzern, auf Dateien in diesem Verzeichnis zuzugreifen (dies lebte, wie viele andere Funktionen, unter Unix).

Multics folgte auch dem Prinzip, einen einzigen Speicherpool zu haben. Das Papier geht nicht auf diesen Aspekt ein. Ein einziger Speicherpool passte gut zur Hardware der damaligen Zeit: Es gab keine austauschbaren Speichergeräte, zumindest keine, die den Benutzern etwas ausmachten würden. Multics verfügte zwar über einen separaten Sicherungsspeicherpool, dieser war jedoch für die Benutzer transparent.

Unix

Unix ließ sich von Multics inspirieren, zielte jedoch auf Einfachheit, wohingegen Multics auf Flexibilität abzielte.

Ein einziges hierarchisches Dateisystem passte gut zu Unix. Wie bei Multics waren Speicherpools für Benutzer normalerweise nicht relevant. Es gab jedoch Wechseldatenträger, die von Unix über die Befehle mountund für Benutzer umountverfügbar gemacht wurden (reserviert für den „Superuser“, dh den Administrator). Dennis Ritchie und Ken Thompson erklären in „The UNIX Time-Sharing System“ :

Obwohl das Stammverzeichnis des Dateisystems immer auf demselben Gerät gespeichert ist, muss sich nicht die gesamte Dateisystemhierarchie auf diesem Gerät befinden. Es gibt eine Mount-Systemanforderung mit zwei Argumenten: dem Namen einer vorhandenen normalen Datei und dem Namen einer speziellen Datei, deren zugeordnetes Speichervolumen (z. B. ein Plattenpaket) die Struktur eines unabhängigen Dateisystems mit einer eigenen Verzeichnishierarchie haben soll . Durch das Einhängen wird bewirkt, dass Verweise auf die bisher übliche Datei auf das Stammverzeichnis des Dateisystems auf dem Wechseldatenträger verweisen. Tatsächlich ersetzt mount ein Blatt des Hierarchiebaums (die normale Datei) durch einen neuen Teilbaum (die auf dem Wechseldatenträger gespeicherte Hierarchie). Nach dem Mounten gibt es praktisch keine Unterscheidung zwischen Dateien auf dem Wechseldatenträger und Dateien im permanenten Dateisystem. In unserer Installation befindet sich das Stammverzeichnis beispielsweise auf einer kleinen Partition eines unserer Festplattenlaufwerke, während das andere Laufwerk, das die Dateien des Benutzers enthält, durch die Systeminitialisierungssequenz bereitgestellt wird. Ein anbringbares Dateisystem wird durch Schreiben auf die entsprechende spezielle Datei generiert. Mit einem Hilfsprogramm können Sie ein leeres Dateisystem erstellen oder einfach ein vorhandenes Dateisystem kopieren.

Das hierarchische Dateisystem hat auch den Vorteil, dass die Komplexität der Verwaltung mehrerer Speichergeräte im Kernel konzentriert wird. Dies bedeutete, dass der Kernel komplexer war, aber alle Anwendungen dadurch einfacher wurden. Da sich der Kernel um Hardwaregeräte kümmern muss, die meisten Anwendungen dies jedoch nicht tun, ist dies ein natürlicheres Design.

Windows

Windows geht auf zwei Abstammungslinien zurück: VMS , ein Betriebssystem, das ursprünglich für den VAX- Minicomputer entwickelt wurde, und CP / M , ein Betriebssystem, das für frühe Intel-Mikrocomputer entwickelt wurde.

VMS hatte ein verteiltes hierarchisches Dateisystem, Files-11 . In Files-11 enthält der vollständige Pfad zu einer Datei einen Knotennamen, eine Kontenbezeichnung auf diesem Knoten, einen Gerätenamen, einen Verzeichnisbaumpfad, einen Dateinamen, einen Dateityp und eine Versionsnummer. VMS verfügte über eine leistungsstarke Funktion für logische Namen , mit der Verknüpfungen zu bestimmten Verzeichnissen definiert werden konnten, sodass sich Benutzer selten um den „tatsächlichen“ Speicherort eines Verzeichnisses kümmern mussten.

CP / M wurde für Computer mit 64 KB RAM und einem Diskettenlaufwerk entwickelt, daher wurde es der Einfachheit halber verwendet. Es gab keine Verzeichnisse, aber ein Dateiverweis könnte eine Laufwerksangabe ( A:oder B:) enthalten.

Als MS-DOS 2.0 Verzeichnisse einführte, tat es dies mit einer Syntax, die mit MS-DOS 1 kompatibel war, das selbst CP / M folgte. So wurzelten Pfade auf einem Laufwerk mit einem einzigen Buchstaben. (Außerdem wurde das Schrägstrichzeichen /in VMS und CP / M zum Starten von Befehlszeilenoptionen verwendet, sodass ein anderes Zeichen als Verzeichnisseparator verwendet werden musste. Aus diesem Grund verwenden DOS und spätere Windows den umgekehrten Schrägstrich, obwohl einige interne Komponenten auch Schrägstriche unterstützen ).

Windows behielt die Kompatibilität mit DOS und dem VMS-Ansatz bei, sodass die Laufwerksbuchstaben beibehalten wurden, auch wenn sie weniger relevant waren. Heute verwendet Windows unter der Haube UNC- Pfade ( ursprünglich von Microsoft und IBM für OS / 2 entwickelt , verwandter Herkunft). Obwohl dies (wahrscheinlich aufgrund des Gewichts des Verlaufs) für Hauptbenutzer reserviert ist, ermöglicht Windows die Bereitstellung über Analysepunkte .

Es gibt keine Sicherheitsbedenken, wenn ein einzelner Verzeichnisbaum vorhanden ist.

Die Entwickler von Unix verfügten über umfangreiche Erfahrungen mit Betriebssystemen, bei denen die Benutzer wissen mussten, auf welchem ​​physischen Gerät sich eine bestimmte Ressource befand. Da ein Teil des Zwecks eines Betriebssystems darin besteht, eine abstrakte Maschine auf der realen Hardware zu erstellen, hielten sie es für viel einfacher, auf die Adressierung von Ressourcen durch ihren physischen Standort zu verzichten, und beschlossen, alles in einem einzigen Namensbaum zusammenzufassen.

Dies ist nur ein Teil des Genies hinter dem Design von Unix .

Beachten Sie, dass die Laufwerksbuchstabennamen von MS-DOS, die in modernen Windows bestehen, hier ein roter Hering sind. Laufwerkbuchstaben sind nicht die beste Darstellung einer Dateisystemstruktur mit mehreren Wurzeln. Sie sind eine Strawman-Implementierung eines solchen Systems.

Ein richtig implementiertes Dateisystem, das mehrere Roots unterstützt, würde eine beliebige Benennung für die Volumes ermöglichen, wie z dvdrom:/path/to/file.avi. Ein solches System würde die lächerlichen Probleme mit der Benutzeroberfläche beseitigen, die Windows plagen. Wenn Sie beispielsweise ein Gerät wie eine Kamera anschließen, werden Sie in der Windows Explorer-Benutzeroberfläche darauf hingewiesen, dass es ein Gerät mit dem Namen Kamera (oder was auch immer) gibt und dass Sie einen Pfad wie diesen haben Computer\Camera\DCIM\.... Wenn Sie jedoch die Textversion dieses Pfads aus dem Explorer ausschneiden und einfügen, funktioniert dies nicht, da einige der Pfadnamenkomponenten eine Fiktion der Benutzeroberfläche sind, die dem zugrunde liegenden Betriebssystem nicht bekannt ist. In einem richtig implementierten System mit mehreren Wurzeln wäre es in Ordnung: Es gäbe einecamera:\DCIM\...Pfad, der auf jeder Ebene des Systems einheitlich erkannt wird. Wenn Sie eine alte Festplatte von einem alten PC aus portieren würden, würden Sie nicht an einen Laufwerksbuchstaben gebunden sein F:, sondern könnten diesen nach Belieben benennen old-disk:.

Wenn also Unix mehrere Roots in der Dateisystemstruktur hätte, würde dies problemlos und nicht wie in MS-DOS und Windows mit Laufwerksnamen mit einem Buchstaben erfolgen. Mit anderen Worten, lassen Sie uns das Unix-Schema nur mit einem guten Multi-Root-Design vergleichen.

Warum hat Unix also keine vernünftige Implementierung mit mehreren Wurzeln anstelle einer vernünftigen Implementierung mit einer Wurzel? Es ist wahrscheinlich nur der Einfachheit halber. Bereitstellungspunkte bieten die gesamte Funktionalität, um über Namen auf Volumes zugreifen zu können. Es ist nicht erforderlich, den Namespace mit einer zusätzlichen Präfixsyntax zu erweitern.

Mathematisch gesehen kann jeder nicht zusammenhängende Baumgraph ("Wald") verbunden werden, indem ein Wurzelknoten hinzugefügt und die nicht zusammenhängenden Teile zu seinen untergeordneten Elementen gemacht werden.

Darüber hinaus ist es flexibler, dass sich die Volumes nicht auf der Root-Ebene befinden müssen. Da es keine spezielle Syntax gibt, die das Volume bezeichnet (es ist nur eine Pfadkomponente), können Mount-Punkte überall sein. Wenn Sie in drei alten Platten auf Ihren Rechner mitbringen, können Sie sie als haben /old-disk/one, /old-disk/twousw. können Sie Festplatten organisieren , wie Sie wollen, wie Sie Dateien und Verzeichnisse organisieren.

Es können Anwendungen geschrieben werden, die von Pfaden abhängen, und die Gültigkeit von Pfaden kann beibehalten werden, wenn die Speichergeräte neu konfiguriert werden. Beispielsweise können Anwendungen bekannte Pfade wie /var/logund verwenden /var/lib. Es liegt an Ihnen, ob /var/logund /var/libauf demselben Datenträger oder auf separaten Datenträgern. Sie können ein System unter Beibehaltung der Pfade auf eine neue Speichertopologie migrieren.

Bereitstellungspunkte sind eine gute Idee. Aus diesem Grund gibt es sie seit Windows 2000.

Volume-Bereitstellungspunkte sind robust gegenüber Systemänderungen, die beim Hinzufügen oder Entfernen von Geräten zu einem Computer auftreten. Microsoft Technet

Sowohl * nix als auch Windows mounten ihre Laufwerke. In Windows werden diese automatisch an Bereitstellungspunkten bereitgestellt, die standardmäßig in aufsteigender alphabetischer Reihenfolge sind. Diese Standardeinstellungen sind:

• A:und B:=> Disketten
• C: => erste Partition der ersten Festplatte
• D: => nächste Partition oder nächste Festplatte oder CD / DVD-Laufwerk, wenn keine anderen Partitionen vorhanden sind.

Jeder dieser Mountpunkte ist ein Verzeichnis.

In * nix werden die Einhängepunkte vom Benutzer festgelegt. Zum Beispiel habe ich eine Partition gemountet als /und eine andere als /home. Wenn /homees sich also um ein separates Laufwerk handelt, entspricht dies beispielsweise E:Windows.

In beiden Fällen, Windows und * nix, sind Bereitstellungspunkte separate Verzeichnisse. Der einzige Unterschied besteht darin, dass in * nix diese separaten Verzeichnisse Unterverzeichnisse von sind /, C:während in Windows jeder Einhängepunkt direkt unter dem eingebunden ist, sagen wir mal /unter My Computer.

Aus Sicht des Benutzers besteht der Hauptvorteil darin, dass die Halterungen vollständig transparent sind. Ich muss nicht wissen, dass sich das Verzeichnis /hometatsächlich auf einer separaten Partition befindet. Ich kann es einfach als normales Verzeichnis verwenden. Stattdessen müsste ich es unter DOS explizit mit dem Namen des Einhängepunkts aufrufenE:\home

Externe Laufwerke werden in beiden Systemen auf die gleiche Weise gemountet. Sprich D:für Windows und /mnt/cdromfür Linux. Jedes von diesen ist ein Verzeichnis, ich sehe den Unterschied nicht wirklich. Wenn Sie unter Windows eine CD-ROM in Ihr Laufwerk einlegen, wird der Datenträger D:wie unter Linux eingehängt .

Ich stimme den obigen Antworten zu, insbesondere der Antwort von Doug O'Neal, aber ich denke, dass sie alle etwas vermissen, ebenso wie die expliziten Geräteeinhängepunkte wie MS-DOS "C:" oder "A:".

Rob Pike schrieb The Hideous Name über die Syntax von Namen, aber Russ Cox brachte es auf den Punkt :

Namensräume ... sind am leistungsfähigsten, wenn neue Semantiken hinzugefügt werden können, ohne dass eine neue Syntax hinzugefügt werden muss.

Ein einziger Namensraum, in dem Geräte beliebig eingehängt werden können, ermöglicht einen wirklich flexiblen Betrieb. Ich benutze /mnt/sdb1und lege regelmäßig /mnt/cdromeine momentan nicht benutzte Diskette oder CD in das gesamte Dateisystem. Es ist überhaupt nicht ungewöhnlich, dass sich Privatverzeichnisse auf einem NFS-Server befinden, sodass Sie unabhängig davon, auf welchem ​​Computer Sie sich anmelden, $HOMEüberall dasselbe erhalten .

Es kommt darauf an: Eine spezielle Syntax für besondere Dinge setzt Ihnen bestimmte Grenzen. Wenn Sie nur eine unbenutzte Festplatte oder CD oder DVD oder ein Netzwerkdateisystem / "share" auf "E:" oder "W:" oder was auch immer mounten können, haben Sie viel weniger Flexibilität.

Das ist dumm. Windows hat auch einen einzelnen Hierarchiepunkt. Aber es ist versteckt und nicht standardisiert. Wie die meisten Dinge Fenster.

In diesem Fall handelt es sich um das Konzept "Arbeitsplatz". Das ist das Äquivalent von root (/) in Unix. Denken Sie daran, dass root ein Konzept ist, das im Kernel existiert. Du magst es oder nicht. So wie Windows den "Arbeitsplatz" behandelt. Natürlich können Sie eine Partition in Unix auf root mounten, und das ist, was die meisten Leute tun. Und viele Dinge betrachten einen bestimmten Pfad für Dinge (z. B. / etc /), aber Sie sind nicht darauf beschränkt. Hängen Sie Ihre Laufwerke auf jeden Fall in / C: / ein. Es ist dir nicht verboten, dies unter Unix zu tun.

C: \ ist kein Root in Windows, sondern der Mount-Punkt einer Partition. Welches MUSS auf der obersten Ebene "Arbeitsplatz" sein. Unter Unix können Sie eine Partition unter einem beliebigen anderen Baum mounten. Linux kann also C: eingebunden haben, /während D: eingebunden ist /mnt/d/... oder sogar /eingebunden, aber das ist schwierig und hängt davon ab, wie sich die beiden Dateisysteme beim Einbinden auf einem bereits eingebundenen Pfad verhalten.

Sie können also genau das Gleiche erreichen wie mit Windows, indem Sie sich "zwingen", dieselben Einschränkungen zu befolgen, die Windows Ihnen zufällig auferlegt.

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

Dann müssten Sie die Mount-Optionen an die Boot-Optionen übergeben. da wirst du kein / etc / ... haben aber das simuliert auch die einschränkungen die fenster auferlegen, als das was es macht.

Der Grund dafür, dass Windows Laufwerksbuchstaben hat, reicht wahrscheinlich weiter zurück als Microsoft und DOS. Das Zuweisen von Buchstaben zu Wechseldatenträgern war auf IBM Systemen üblich, daher hat Microsoft möglicherweise nur die Anweisungen von IBM befolgt, indem CP / M kopiert wurde. Und anfangs hatte DOS sowieso keine Verzeichnisse.

Wenn MS-DOS auf Computern mit einem oder zwei Wechseldatenträgern und keinem festen Datenträger ausgeführt wurde, brauchte man eigentlich kein Dateisystem mit Verzeichnissen. Mit einer oder vielleicht zwei 180-Kilobyte-Festplatten hatten Sie nie genug Dateien, um sie schwer zu organisieren.

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

Tatsächlich basiert Linux auf Unix (oder Unix, siehe Diskussion ) und Unix stammt aus der Mainframe-Umgebung, in der die Verwendung mehrerer Geräte offensichtlich war. Das Mounten von Geräten in einem einzigen Verzeichnisbaum bietet Ihnen maximale Flexibilität und beschränkt nicht die Anzahl der Geräte, auf die das Betriebssystem zugreifen kann.

Auf der anderen Seite sind DOS-Buchstaben für Laufwerke ein gutes Design für einen PC mit 1 oder 2 Diskettenstationen und einem einzelnen Laufwerk. Die große Diskette 5,25 'ist immer A :, die kleine 3,5' ist immer B: und das Laufwerk ist immer C :. Sie wissen immer, ob Sie eine Datei auf die Diskette oder irgendwo auf die Diskette kopieren. Sie benötigen keine Flexibilität, wenn Sie nicht mehr als 2 Diskettenlaufwerke und 2 (oder 4) Festplatten physisch verbinden können.

DOS-Design war benutzerfreundlicher, während Unix-Design für Administratoren geeignet ist. Jetzt stellen Laufwerksbuchstaben eine Belastung für Windows dar. Benutzer verlassen sich mehr darauf, dass das Explorer-Fenster mit dem Inhalt eines Wechseldatenträgers automatisch geöffnet wird, als dass sie dessen Buchstaben kennen ... Ubuntu macht das auch.

Das stimmt eigentlich nicht. Windows verwendet ein anderes Pfadschema (nun ja, nicht dasselbe)

"Unit Letters" sind nur etwas, an das man sich leicht Pfade, Festplatten und Partitionen merken kann.

ARC-Pfade definieren den Pfad einer Datei in Windows (sie sind jedoch nur beim Booten für den Benutzer sichtbar):

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

In Windows NT gibt es keine Beziehung zwischen Festplatten, Partitionen und Einheitenbuchstaben: Sie können ein gesamtes Volume in einem Ordner "ablegen" (z. B .: c: \ myseconddisk könnte eine gesamte physische Festplatte sein!)

Zwei Dinge, auf die ich hinweisen möchte -

1. Festplatten in Linux werden tatsächlich in gewisser Weise Buchstaben / Namen zugewiesen, wie / dev / sdb1. Sie können jedoch überall montiert werden, um von der Single- / Root-Struktur aus erreicht zu werden
2. Der häufigste Grund, warum Menschen (einschließlich meiner selbst in der Vergangenheit) separate Laufwerke in Windows hatten, bestand darin, Dokumente, Musik, Programme usw. an einem Ort aufzubewahren, an dem Windows unweigerlich neu installiert oder ersetzt werden musste, sei es ein Upgrade oder ein Virus oder Dateisystemfehler, es gab immer noch Zugriff auf diese Dateien. Ich habe dieses Problem nicht unter Linux - das Dateisystem ist viel zuverlässiger, das Betriebssystem bricht nur durch eine direkte Aktion oder durch einen Fehler von meiner Seite (ooh! Ein hochaktuelles Repo, lass es uns versuchen!) Und Upgrades sind viel einfacher. Und in dem seltenen Fall musste ich neu installieren, da die gesamte Software über die von mir hinzugefügten Repos oder PPAs verfügbar war (und ich mein Home-Verzeichnis problemlos mit einer Live-Festplatte kopieren konnte).

Wenn Sie in die Geschichte zurückblicken, können Sie auch feststellen, dass Unix zur Zeit von 8-Spur-Bandsystemen für Audio und 9-Spur-IBM-Datensystemen (8 Spuren / 8 Bits für Daten, eine für Parität) gestartet wurde. Technisch sehr ähnlich.

Zu diesem Zeitpunkt wurden die Informationen über den Speicherort von Dateien in Teilen der Informationen auf Band gespeichert und vorwärts und rückwärts definiert, wenn Sie Daten vom Band lesen (wie eine Datei mit Anfangsposition und Endsignatur). Dies erklärt auch, warum Sie zu Beginn des Laufwerks nicht nur eine FAT hatten - Sie hatten mehrere, um die Suche zu beschleunigen. Und wenn Sie mehrere Laufwerke hatten, wurden diese innerhalb von / dev und über die Adresse der Datei, die Sie zwischen den Geräten verschoben haben, verknüpft.

Ich glaube, Sie könnten die Ansicht haben, dass es einfach früher angefangen hat und dass die Entscheidung hinter MS Dos (CP / M) und später Windows NT einfach mit den Laufwerksbuchstaben von VM-Mainframes zusammenhängt, anstatt mit einem einzigen Einstiegspunkt, denn zu der Zeit sah es so aus moderner, Datenmengen von heute existierten nicht und sie dachten nicht, dass Sie schließlich nicht genug Laufwerksbuchstaben haben würden oder dass es überladen wäre.

9-Spur-Laufwerk und Laufwerksbuchstabenzuordnung