
Ich verstehe, was Mounten in Linux ist, und ich verstehe Gerätedateien. Ich verstehe jedoch nicht, WARUM wir mounten müssen.
Wie beispielsweise in derakzeptierte Antwort auf diese Frage, mit diesem Befehl:
mount /dev/cdrom /media/cdrom
Wir mounten das CD-ROM-Gerät /media/cdrom
und können schließlich mit dem folgenden Befehl auf die Dateien der CD-ROM zugreifen
ls /media/cdrom
Darin wird der Inhalt der CD-ROM aufgelistet.
Warum überspringen Sie die Montage nicht ganz und gehen wie folgt vor?
ls /dev/cdrom
Und lassen Sie den Inhalt der CD-ROM auflisten. Ich erwarte, dass eine der Antworten lautet: „So ist Linux konzipiert". Aber wenn das so ist, warum wurde es dann so konzipiert? Warum wird nicht /dev/cdrom
direkt auf das Verzeichnis zugegriffen? Was ist der eigentliche Zweck des Mountens?
Antwort1
Ein Grund dafür ist, dass der Zugriff auf Blockebene etwas niedriger ist, als ls
es möglich wäre. /dev/cdrom
, oder dev/sda1
vielleicht Ihr CD-ROM-Laufwerk bzw. die Partition 1 Ihrer Festplatte, aber sie implementieren nicht ISO 9660 / ext4 - sie sind nur RAW-Zeiger auf diese Geräte, die alsGerätedateien.
Eines der Dinge, die Mount bestimmt, ist, WIE dieser Rohzugriff verwendet wird – welche Dateisystemlogik/Treiber/Kernelmodule die Lese-/Schreibvorgänge verwalten oder übersetzen, ls /mnt/cdrom
in welche Blöcke gelesen werden müssen, und wie der Inhalt dieser Blöcke in Dinge wie … interpretiert wird file.txt
.
In anderen Fällen reicht dieser Zugriff auf niedriger Ebene aus. Ich habe gerade von seriellen Ports, USB-Geräten, TTY-Terminals und anderen relativ einfachen Geräten gelesen und auf diese geschrieben. Ich würde nie versuchen, manuell von /dev/sda1 zu lesen/schreiben, um beispielsweise eine Textdatei zu bearbeiten, weil ich im Grunde die ext4-Logik neu implementieren müsste, was unter anderem Folgendes umfassen könnte: Datei-Inodes nachschlagen, Speicherblöcke finden, den gesamten Block lesen, meine Änderungen vornehmen, die gesamten Blöcke schreiben, dann den Inode aktualisieren (vielleicht) oder stattdessen das alles in das Journal schreiben – viel zu schwierig.
Sie können sich selbst davon überzeugen, indem Sie es einfach ausprobieren:
[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory
/dev
ist ein Verzeichnis, und Sie können cd
so ls
viel tun, wie Sie möchten. /dev/sda1
ist kein Verzeichnis, sondern ein spezieller Dateityp, den der Kernel als „Handle“ für dieses Gerät anbietet.
Sehender Wikipedia-Eintrag zu Gerätedateienfür eine eingehendere Behandlung.
Antwort2
Grundsätzlich und einfach ausgedrückt muss das Betriebssystem wissen, wie es auf die Dateien auf diesem Gerät zugreifen kann.
mount
bedeutet nicht nur, dass Sie „Zugriff auf die Dateien erhalten“, sondern dem Betriebssystem auch mitzuteilen, welches Dateisystem das Laufwerk hat, ob es schreibgeschützt ist oder Lese-/Schreibzugriff hat usw.
/dev/cdrom
ist ein Low-Level-Gerät, die Betriebssystemfunktionen wüssten nicht, wie sie darauf zugreifen sollen ... Stellen Sie sich vor, Sie legen eine seltsam formatierte CD-ROM ein (sogar eine Audio-CD). Wie könnten Sie ls
feststellen, welche Dateien (falls vorhanden) sich auf der CD-ROM befinden, ohne sie zuerst zu „mounten“?
Beachten Sie, dass dies bei vielen Betriebssystemen automatisch geschieht (bei einigen Distributionen und mit einigen Grafikschnittstellen sogar bei Linux). Das heißt aber nicht, dass andere Betriebssysteme die Laufwerke nicht „mounten“.
Antwort3
Ich würde sagen, es sind historische Gründe. Nicht, dass die anderen Antworten falsch wären, aber die Geschichte hat noch mehr zu bieten.
Vergleichen Sie Windows: Windows begann als Betriebssystem für einen einzelnen Computer und einen einzelnen Benutzer. Dieser einzelne Computer hatte wahrscheinlich ein Diskettenlaufwerk und eine Festplatte, keine Netzwerkverbindung, kein USB, nichts. (Windows 3.11 hatte native Netzwerkfunktionen;Windows 3.1 hat nicht.)
Die Grundeinstellung von Windows war so einfach, dass es keiner Extravaganz bedurfte: Einfach jedes Mal alles (alle zwei Geräte) automatisch mounten, es konnte (gab) nicht viel schiefgehen.
Im Gegensatz dazu wurde Unix von Anfang an für die Ausführung auf Servernetzwerken mit mehreren Benutzern entwickelt.
Eine der Designentscheidungen von Unix bestand darin, dass das Dateisystem für den Endbenutzer als einheitliche Einheit erscheinen sollte, unabhängig davon, auf wie viele Computer die physischen Datenträger verteilt waren, unabhängig davon, um welche Art von Datenträger es sich handelte und unabhängig davon, von welchem der Dutzenden von Computern aus der Benutzer darauf zugriff. Der logische Pfad zu den Dateien des Benutzers bliebe derselbe, selbst wenn sich der physische Speicherort dieser Dateien über Nacht geändert hatte, z. B. aufgrund von Serverwartungen.
Sie abstrahierten das logische Dateisystem, also die Pfade zu den Dateien, von den physischen Geräten, auf denen diese Dateien gespeichert waren. Angenommen, Server A hostet normalerweise /home, aber Server A muss gewartet werden: Hängen Sie Server A einfach ab und mounten Sie stattdessen Backup-Server B auf /home, und niemand außer den Administratoren würde es überhaupt bemerken.
(Im Gegensatz zur Windows-Konvention, verschiedenen physischen Geräten verschiedene Namen zu geben – C:, D: usw. –, was der Transparenz entgegenwirkt, die Unix anstrebte.)
In einer solchen Umgebung kann man nicht einfach alles aufs Geratewohl montieren,
In einem großen Netzwerk sind einzelne Festplatten und Computer ständig außer Betrieb. Administratorenbrauchendie Möglichkeit anzugeben, was wo und wann gemountet wird, z. B. um einen Computer kontrolliert herunterzufahren, während ein anderer Computer transparent das Hosten derselben Dateien übernimmt.
Aus historischer Sicht ist das der Grund: Windows und Unix haben unterschiedliche Hintergründe. Man könnte es einen kulturellen Unterschied nennen, wenn man so will:
- Unix entstand in einer Umgebung, in der der Administrator die Einbindung kontrollieren musste; der Administrator musste entscheiden, was von den Dutzenden von Speichergeräten im Netzwerk wo und wann eingebunden wurde.
- Bei der Geburt von Windows gab es keinen Administrator und nur zwei Speichergeräte. Der Benutzer wusste wahrscheinlich, ob sich seine Datei auf der Diskette oder der Festplatte befand.
- (Linux wurde natürlich als Betriebssystem für einen einzelnen Computer entwickelt, wurde aber von Anfang an auch explizit darauf ausgelegt, Unix auf einem Heimcomputer so genau wie möglich zu imitieren.)
In jüngster Zeit haben sich die Betriebssysteme einander angenähert:
- Linux hat mehr Funktionen für Einzelcomputer und Einzelbenutzer hinzugefügt (z. B. Automounting), da es häufig in Einzelcomputereinstellungen verwendet wird.
- Unter Windows wurden mehr Sicherheit, Netzwerkfunktionen, Unterstützung für mehrere Benutzer usw. hinzugefügt, da Netzwerke immer allgegenwärtiger wurden und Microsoft auch mit der Entwicklung eines Betriebssystems für Server begann.
Dennoch lässt sich leicht erkennen, dass beide das Ergebnis unterschiedlicher Traditionen sind.
Antwort4
Der Fragentitel lautet:Warum müssen wir unter Linux mounten?
Eine Möglichkeit, diese Frage zu interpretieren:Warum müssen wir explizite mount
Befehle ausgeben, um Dateisysteme unter Linux verfügbar zu machen?
Die Antwort: Nein, das tun wir nicht.
Sie müssen Dateisysteme nicht explizit mounten, Sie können es automatisch erledigen lassen und Linux-Distributionen tun dies bereits für die meisten Geräte, genau wie Windows und Macs.
Das ist also wahrscheinlich nicht die Frage, die Sie stellen wollten.
Eine zweite Interpretation:Warum tun wirManchmalmüssen explizite mount
Befehle ausgegeben werden, um Dateisysteme unter Linux verfügbar zu machen? Warum nicht das Betriebssystemstetsfür uns erledigen und vor dem Benutzer verbergen?
Dies ist die Frage, die ich im Fragetext lese, wenn Sie fragen:
Warum nicht die Montage ganz überspringen und Folgendes tun
ls /dev/cdrom
und den Inhalt der CD-ROM aufgelistet haben?
Vermutlich meinen Sie: Warum lässt man diesen Befehl nicht einfach das tun, was
ls /media/cdrom
tut es jetzt?
Nun, in diesem Fall /dev/cdrom
wäre es ein Verzeichnisbaum und keine Gerätedatei. Ihre eigentliche Frage scheint also zu sein: Warum gibt es überhaupt eine Gerätedatei?
Ich möchte den bereits gegebenen Antworten eine weitere hinzufügen.
Warum erhalten Benutzer Zugriff auf Gerätedateien?
Wenn Sie eine CD-ROM oder ein anderes Gerät zum Speichern von Dateien verwenden, wird eine Software verwendet, die den Inhalt Ihrer CD-ROM als Verzeichnisbaum von Dateien interpretiert. Sie wird aufgerufen, wenn Sie einen ls
anderen Befehl oder eine andere Anwendung verwenden, die auf die Dateien auf Ihrer CD-ROM zugreift. Diese Software ist der Dateisystemtreiber für das bestimmte Dateisystem, das zum Schreiben der Dateien auf Ihre CD-ROM verwendet wird. Wenn Sie Dateien auf einem Dateisystem auflisten, lesen oder schreiben, ist es die Aufgabe dieser Software, sicherzustellen, dass die entsprechenden Lese- und Schreibvorgänge auf niedriger Ebene auf dem betreffenden Gerät ausgeführt werden. Wenn Sie mount
ein Dateisystem verwenden, teilen Sie dem System mit, welcher Dateisystemtreiber für das Gerät verwendet werden soll. Unabhängig davon, ob Sie dies explizit mit einem mount
Befehl tun oder es dem Betriebssystem überlassen, es automatisch auszuführen, muss es ausgeführt werden, und natürlich muss die Dateisystemtreibersoftware zunächst vorhanden sein.
Wie erledigt ein Dateisystemtreiber seine Aufgabe? Die Antwort: Er tut dies, indem er aus der Gerätedatei liest und in sie schreibt. Warum? Die Antwort, wie Sie bereits angegeben haben: Unix wurde so konzipiert. In Unix sind Gerätedateien die gemeinsame Low-Level-Abstraktion für Geräte. Die wirklich gerätespezifische Software (der Gerätetreiber) für ein bestimmtes Gerät soll das Öffnen, Schließen, Lesen und Schreiben auf dem Gerät als Vorgänge auf der Gerätedatei implementieren. Auf diese Weise muss höherstufige Software (wie ein Dateisystemtreiber) nicht so viel über die interne Funktionsweise einzelner Geräte wissen. Die Low-Level-Gerätetreiber und die Dateisystemtreiber können separat von verschiedenen Personen geschrieben werden, solange sie sich auf eine gemeinsame Art der Schnittstelle einigen, und genau dafür sind die Gerätedateien da.
Daher benötigen Dateisystemtreiber die Gerätedateien.
Aber warum bekommen wir, normale Benutzer, die Gerätedateien zu sehen? Die Antwort ist, dass Unix für die Verwendung durch Betriebssystemprogrammierer entwickelt wurde. Es wurde entwickelt, um seinen Benutzern das Schreiben von Gerätetreibern und Dateisystemtreibern zu ermöglichen. Und so werden sie tatsächlich geschrieben.
Dasselbe gilt für Linux: Sie können Ihren eigenen Dateisystemtreiber (oder Gerätetreiber) schreiben, ihn installieren und dann verwenden. Dadurch ist Linux (oder jede andere Unix-Variante) leicht erweiterbar (und das ist tatsächlich der Grund, warum Linux überhaupt eingeführt wurde): Wenn eine neue Hardware auf den Markt kommt oder eine neue, intelligentere Methode zur Implementierung eines Dateisystems entwickelt wird, kann jemand den Code zur Unterstützung schreiben, ihn zum Laufen bringen und ihn zu Linux beitragen.
Gerätedateien erleichtern dies.