Betreff: Betriebssysteme.
Frage: Nr. 8

—————————————————————

Prinzipien des Betriebssystemdesigns:

1.) Das Prinzip der Modularität– Im Allgemeinen wird unter einem Modul ein funktional vollständiges Element des Systems verstanden, das gemäß akzeptierten intermodularen Schnittstellen hergestellt wird. Ein Modul geht per Definition davon aus, dass es problemlos durch ein anderes ersetzt werden kann, wenn die angegebenen Schnittstellen verfügbar sind. Die Aufteilung des Systems in Module wird zu einem großen Teil durch die verwendete OS-Designmethode bestimmt (Bottom-Up oder umgekehrt).

Von besonderer Bedeutung beim Aufbau eines Betriebssystems sind privilegierte, wiedereintretende und wiedereintretende Module (Wiedereintritt – wörtlich Wiedereintritt; Sonderbegriff um die Funktionalität des Programms anzuzeigen; Eigenschaft eines Programms, um bei einem rekursiven (zurückgegebenen) Aufruf von einem Interrupt korrekt ausgeführt zu werden).

Die größte Wirkung dieses Prinzips lässt sich erzielen, wenn dieses Prinzip gleichzeitig auf das Betriebssystem, die Anwendungsprogramme und die Hardware übertragen wird.

2.) Das Prinzip der funktionalen Selektivität– Das Betriebssystem weist einen bestimmten Teil wichtiger Module zu, die ständig vorhanden sein müssen RAM für eine effizientere Organisation des Rechenprozesses. Dieser Teil des Betriebssystems wird Kernel genannt, da er die Basis des Systems bildet. Bei der Zusammensetzung des Kerns müssen zwei gegensätzliche Anforderungen berücksichtigt werden. Einerseits sollte der Kernel die am häufigsten verwendeten Systemmodule enthalten, andererseits sollte die Anzahl der Module so bemessen sein, dass der vom Kernel belegte Speicher nicht zu groß wird. Neben den Programmmodulen, die Teil des Kernels sind und sich dauerhaft im RAM befinden, kann es noch viele weitere geben Systemprogramme Abschlussmodule, die aufgerufen werden Transit. Transit-Programmmodule werden nur bei Bedarf in den RAM geladen und können, wenn kein freier Speicherplatz vorhanden ist, durch andere Transit-Module ersetzt werden.

3.) Prinzip der Betriebssystemgenerierung: Der Kern des Prinzips besteht darin, eine solche Methode der anfänglichen Darstellung des zentralen Systemsteuerungsprogramms des Betriebssystems (den Kernel und die Hauptkomponenten, die sich dauerhaft im RAM befinden) zu organisieren (auszuwählen), die es ermöglicht, diesen Systemüberwachungsteil zu konfigurieren basierend auf der spezifischen Konfiguration eines bestimmten Rechenkomplexes und dem Spektrum der zu lösenden Aufgaben. Dieser Vorgang wird selten vor einer längeren Betriebszeit des Betriebssystems durchgeführt. Der Generierungsprozess erfolgt über ein spezielles Generatorprogramm und die entsprechende Eingabesprache für dieses Programm, mit der Sie die Softwarefähigkeiten des Systems und die Konfiguration der Maschine beschreiben können. Das Ergebnis der Generation ist Vollversion Betriebssystem. Die generierte Betriebssystemversion ist eine Sammlung von Systemsätzen aus Modulen und Daten.

4.) Das Prinzip der funktionalen Redundanz: Dieses Prinzip berücksichtigt die Möglichkeit, die gleiche Arbeit mit unterschiedlichen Mitteln auszuführen. Das Betriebssystem kann mehrere Arten von Monitoren (Supervisor-Module, die die eine oder andere Art von Ressource verwalten) und verschiedene Mittel zur Organisation der Kommunikation zwischen Computerprozessen umfassen. Das Vorhandensein mehrerer Arten von Monitoren und mehrerer Dateiverwaltungssysteme ermöglicht es Benutzern, das Betriebssystem schnell und am besten an eine bestimmte Computersystemkonfiguration anzupassen, die effizienteste Auslastung der Hardware bei der Lösung einer bestimmten Klasse von Problemen sicherzustellen und bei der Lösung maximale Leistung zu erzielen eine bestimmte Klasse von Problemen.

5.) Prinzip der Virtualisierung: Der Aufbau virtueller Ressourcen, deren Verteilung und Nutzung wird derzeit in fast jedem Betriebssystem verwendet. Dieses Prinzip ermöglicht es uns, die Struktur des Systems in Form eines bestimmten Satzes von Prozessplanern und Ressourcenzuweisern (Monitoren) darzustellen und ein einziges zentralisiertes Schema für die Ressourcenverteilung zu verwenden.

Die natürlichste und vollständigste Manifestation des Konzepts der Virtualität ist das Konzept virtuelle Maschine . Die dem Benutzer bereitgestellte virtuelle Maschine reproduziert die Architektur der realen Maschine, die Architekturelemente in dieser Darstellung erscheinen jedoch mit neuen oder verbesserten Eigenschaften, was in der Regel die Arbeit mit dem System vereinfacht. Die Eigenschaften können beliebig sein, aber am häufigsten möchten Benutzer ihre eigene „ideale“ Maschine in Bezug auf architektonische Eigenschaften haben, bestehend aus Folgendem:

— virtueller Speicher mit praktisch unbegrenzter Kapazität und einheitlicher Betriebslogik.

— eine beliebige Anzahl virtueller Prozessoren, die parallel arbeiten und während des Betriebs interagieren können.

– eine beliebige Anzahl externer virtueller Geräte, die mit dem Speicher einer virtuellen Maschine parallel oder sequentiell, asynchron oder synchron in Bezug auf den Betrieb eines bestimmten virtuellen Prozessors arbeiten können, der den Betrieb dieser Geräte initiiert.

Einer der Aspekte der Virtualisierung ist die Organisation der Fähigkeit, Anwendungen auf einem bestimmten Betriebssystem auszuführen, die für andere Betriebssysteme entwickelt wurden. Mit anderen Worten: Wir sprechen über die Organisation mehrerer Betriebsumgebungen.

6.) Das Prinzip der Programmunabhängigkeit von externe Geräte: Dieses Prinzip ist mittlerweile in den allermeisten allgemeinen Betriebssystemen implementiert. Erstmals wurde dieses Prinzip im UNIX-Betriebssystem am konsequentesten umgesetzt. Es ist auch in den meisten modernen PC-Betriebssystemen implementiert. Dieses Prinzip besteht darin, dass die Verbindung von Programmen mit bestimmte Geräte erfolgt nicht auf der Ebene der Ausstrahlung des Programms, sondern während des Planungszeitraums für seine Durchführung. Dadurch ist keine Neukompilierung erforderlich, wenn das Programm auf einem neuen Gerät ausgeführt wird, auf dem sich die Daten befinden.

7.) Kompatibilitätsprinzip: Ein Aspekt der Kompatibilität ist die Fähigkeit des Betriebssystems, Programme auszuführen, die für andere oder andere Betriebssysteme geschrieben wurden frühere Versionen dieses Betriebssystem sowie für andere Hardwareplattformen. Es ist notwendig, die Fragen zu trennen Binärkompatibilität Und Quellkompatibilität Anwendungen.

Binärkompatibilität wird erreicht, wenn Sie ein ausführbares Programm auf einem anderen Betriebssystem ausführen können. Dies erfordert Kompatibilität auf Prozessorbefehlsebene und Kompatibilität auf Systemaufrufebene und sogar auf Bibliotheksaufrufebene, wenn sie dynamisch verknüpft sind.

Die Kompatibilität auf Quelltextebene erfordert die Anwesenheit eines geeigneten Übersetzers als Teil des Systems Software sowie Kompatibilität auf Bibliotheks- und Systemaufrufebene. In diesem Fall ist eine Neukompilierung der vorhandenen Quelltexte in ein neues ausführbares Modul erforderlich.

Es ist viel schwieriger, eine binäre Kompatibilität zwischen Prozessoren zu erreichen, die auf unterschiedlichen Architekturen basieren. Damit ein Computer die Programme eines anderen ausführen kann (beispielsweise sollte ein Programm für einen PC wie einen IBM-PC vorzugsweise auf einem PC wie einem Apple Macintosh ausgeführt werden), muss dieser Computer mit zunächst unverständlichen Maschinenanweisungen arbeiten dazu. In diesem Fall muss ein 680x0-Prozessor (oder PowerPC) Binärcode ausführen, der für einen i80x86-Prozessor entwickelt wurde. Der 80x86-Prozessor verfügt über einen eigenen Befehlsdecoder, eigene Register und eine eigene interne Architektur. Ein 680x0-Prozessor versteht keinen 80x86-Binärcode, daher muss er jede Anweisung abrufen und dekodieren, um festzustellen, was

was es tun soll, und führen Sie dann die entsprechende Routine aus, die für 680x0 geschrieben wurde.

Eines der Mittel zur Gewährleistung der Kompatibilität zwischen Software und Benutzeroberflächen ist die Einhaltung der POSIX-Standards, deren Verwendung es Ihnen ermöglicht, Programme im UNIX-Stil zu erstellen, die problemlos von einem System auf ein anderes übertragen werden können.

8.) Das Prinzip der Offenheit und Skalierbarkeit: Ein offenes Betriebssystem steht sowohl Benutzern als auch Systemspezialisten, die das Computersystem warten, zur Analyse zur Verfügung. Ein erweiterbares (modifiziertes, entwickeltes) Betriebssystem ermöglicht Ihnen nicht nur die Nutzung von Generierungsfunktionen, sondern auch die Einführung neuer Module in seine Zusammensetzung, die Verbesserung vorhandener Module usw. Mit anderen Worten: Es sollte möglich sein, bei Bedarf problemlos Ergänzungen und Änderungen vorzunehmen, ohne die Integrität des Systems zu beeinträchtigen. Hervorragende Erweiterungsmöglichkeiten bietet der Client-Server-Ansatz zur Strukturierung des Betriebssystems mittels Micro-Kernel-Technologie. Gemäß diesem Ansatz besteht das Betriebssystem aus einer Reihe privilegierter Steuerprogramme und einer Reihe unprivilegierter Dienste (Server). Der Hauptteil des Betriebssystems bleibt unverändert, gleichzeitig können neue Server hinzugefügt oder alte verbessert werden. Dieses Prinzip wird manchmal als interpretiert Erweiterbarkeit des Systems.

9.) Mobilitätsprinzip: Das Betriebssystem sollte relativ einfach zu portieren sein

Übertragung von einem Prozessor eines Typs auf einen Prozessor eines anderen Typs und von einer Hardwareplattform eines Typs, die neben dem Prozessortyp auch die Methode zur Organisation der gesamten Computerhardware (Computersystemarchitektur) umfasst, auf eine Hardwareplattform von ein anderer Typ. Beachten Sie, dass das Prinzip der Portabilität dem Prinzip der Kompatibilität sehr nahe kommt, obwohl sie nicht dasselbe sind. Das Erstellen eines tragbaren Betriebssystems ähnelt dem Schreiben von tragbarem Code, Sie müssen jedoch einige befolgen Regeln:

— Der Großteil des Betriebssystems muss in einer Sprache ausgeführt werden, die auf allen Systemen verfügbar ist, auf die es in Zukunft übertragen werden soll. Dies bedeutet zunächst einmal, dass das Betriebssystem in der Sprache geschrieben sein muss hohes Niveau, vorzugsweise standardisiert, zum Beispiel in der Sprache C. Ein in Assembler geschriebenes Programm ist im Allgemeinen nicht portierbar.

- Es ist wichtig, die Teile des Codes, die direkt mit der Hardware interagieren, zu minimieren oder, wenn möglich, zu eliminieren. Hardwareabhängigkeit kann viele Formen annehmen. Zu den offensichtlichen Formen der Abhängigkeit gehört die direkte Manipulation von Registern und anderer Hardware. Wenn schließlich hardwareabhängiger Code nicht vollständig eliminiert werden kann, sollte er in mehreren gut lokalisierten Modulen isoliert werden. Hardwareabhängiger Code sollte nicht im gesamten System verteilt werden. Sie können beispielsweise eine geräteabhängige Struktur in programmdefinierten Daten eines abstrakten Typs ausblenden.

Mit der Einführung der POSIX-Standards sollte die Portabilität der entstehenden Software sichergestellt werden.

10.) Prinzip der Computersicherheit: Die Gewährleistung der Sicherheit bei der Durchführung von Berechnungen ist eine wünschenswerte Eigenschaft für jedes Mehrbenutzersystem. Sicherheitsregeln definieren Eigenschaften wie den Schutz der Ressourcen eines Benutzers vor anderen und das Festlegen von Ressourcenkontingenten, um zu verhindern, dass ein Benutzer alle Systemressourcen, wie z. B. Speicher, übernimmt.

Der Schutz von Informationen vor unbefugtem Zugriff ist eine zwingende Funktion von Netzwerkbetriebssystemen.

—————————————————————

Was ist passiertPOSIX: Plattformunabhängige Systemschnittstelle für Computerumgebungen POSIX (Portable Operating System Interface for Computer Environments) ist ein IEEE-Standard (Institute of Electrical and Electronics Engineers), der Systemschnittstellen für offene Betriebssysteme beschreibt, einschließlich Shells, Dienstprogramme und Toolkits. Darüber hinaus werden laut POSIX Sicherheitsaufgaben, Echtzeitaufgaben, Verwaltungsprozesse, Netzwerkfunktionen und Transaktionsverarbeitung standardisiert. Der Standard basiert auf UNIX-Systemen, kann aber auch in anderen Betriebssystemen implementiert werden. POSIX entstand als Versuch des weltbekannten IEEE, die Anwendungsportabilität in UNIX-Umgebungen durch die Entwicklung eines abstrakten, plattformunabhängigen Standards zu fördern. Beispielsweise entspricht das bekannte Echtzeit-Betriebssystem QNX den Spezifikationen dieses Standards.

Dieser Standard beschreibt das System im Detail virtueller Speicher VMS- (Virtual Memory System), MPE- (Multi-Process Executing) Multitasking- und CTOS-Technologie (An Operating System Produced Convergent Technology...) zur Übertragung von Betriebssystemen. POSIX ist also eigentlich eine Reihe von Standards namens POSIX.I bis POSIX.12. Besonders zu beachten ist auch, dass POSIX.1 C als Hauptsprache voraussetzt

Sprache zur Beschreibung von System-API-Funktionen.

Daher werden nach diesen Standards geschriebene Programme auf allen POSIX-kompatiblen Systemen gleich ausgeführt. In einigen Fällen hat der Standard jedoch nur beratenden Charakter. Einige der Standards sind sehr streng beschrieben, während andere die grundlegenden Anforderungen nur oberflächlich offenbaren.

Implementierungen der POSIX-API auf Ebene Betriebssystem sind unterschiedlich. Während die überwiegende Mehrheit der UNIX-Systeme zunächst den Spezifikationen des IEEE-Standards 1003.1-1990 entspricht, ist WinAPI nicht POSIX-kompatibel. Um diesen Standard zu unterstützen, hat das Betriebssystem MS Windows NT jedoch ein spezielles POSIX-API-Unterstützungsmodul eingeführt, das auf der Berechtigungsebene von Benutzerprozessen arbeitet.

Dieses Modul ermöglicht die Konvertierung und Übertragung von Aufrufen von einem Benutzerprogramm zum Systemkernel und zurück und arbeitet mit dem Kernel über die Win-API. Andere mit WinAPI erstellte Anwendungen können Informationen über Standard-I/O-Stream-Mechanismen (stdin, stdout) an POSIX-Anwendungen übergeben.

Es gibt keine ähnlichen Beiträge...

POSIX (Portable Operating System Interface for Computer Environments) ist ein IEEE-Standard (Institute of Electrical and Electronics Engineers), der Systemschnittstellen beschreibt.

„In diesem Zusammenhang ist unter Systembefehlen eine bestimmte Menge von Programmen zu verstehen, mit denen man Rechenprozesse steuern kann, zum Beispiel pstat, kill, dir usw.

POSIX-Schnittstelle________________________________________________________ 305

Gesichter für offene Betriebssysteme, einschließlich Shells, Dienstprogramme und Tools. Darüber hinaus werden laut POSIX Sicherheitsaufgaben, Echtzeitaufgaben, Verwaltungsprozesse, Netzwerkfunktionen und Transaktionsverarbeitung standardisiert. Der Standard basiert auf UNIX-Systemen, kann aber auch in anderen Betriebssystemen implementiert werden.

Die POSIX-Schnittstelle begann als Versuch des IEEE, die Anwendungsportabilität in UNIX-Umgebungen durch die Entwicklung eines abstrakten, plattformunabhängigen Standards zu fördern. POSIX ist jedoch nicht auf UNIX-Systeme beschränkt; Es gibt verschiedene Implementierungen dieses Standards in Systemen, die den Anforderungen des IEEE-Standards 1003.1-1990 (POSIX.1) entsprechen. Beispielsweise entspricht das bekannte Echtzeit-Betriebssystem QNX den Spezifikationen dieses Standards, was die Portierung von Anwendungen auf dieses System erleichtert, es handelt sich jedoch in keiner Form um ein UNIX-System, da seine Architektur völlig andere Prinzipien verwendet.

Dieser Standard beschreibt die Technologie Virtual Memory System (VMS), Multiprocess Executing (MPE) und Portable Operating System (CTOS). POSIX besteht also eigentlich aus vielen POSIX-Standards. 1-POSIX. 12. In der Tabelle. 9.1 listet die Hauptbereiche auf, die in diesen Standards beschrieben werden. Besonders zu beachten ist auch, dass in POSIX. 1 Als Hauptsprache zur Beschreibung der System-API-Funktionen wird C angenommen.

Tabelle 9.1. POSIX-Standardfamilie

Standard-ISO-Standard-Kurzbeschreibung

POSIX.0 Keine Einführung in den Open-Systems-Standard. Dieses Dokument

ist kein Standard in reiner Form, sondern stellt Empfehlungen dar und kurzer Überblick Technologien

POSIX.1 Ja System-API (C-Sprache)

POSIX.2 Keine Shells und Dienstprogramme (IEEE-zugelassen)

POSIX.3 Kein Testen und Verifizieren

POSIX.4 Keine Echtzeitaufgaben und Ausführungsthreads

POSIX.5 Ja Verwendung der ADA-Sprache anwendbar

nach dem POSIX-Standard. 1

POSIX.6 Keine Systemsicherheit

POSIX.7 Nein Systemadministration

POSIX.8 Kein Netzwerk, transparenter Dateizugriff, abstrakt

Netzwerkschnittstellen, unabhängig von physikalischen Protokollen, RPC-Aufrufen, Systemkommunikation mit protokollabhängigen Anwendungen

POSIX.9 Ja Verwendung der Fortran-Sprache, anwendbar

nach dem POSIX-Standard. 1

POSIX. 10 Kein Super-Computing Application Environment Profile (AEP)

POSIX. 11 Keine AEP-Transaktionsverarbeitung

POSIX. 12 Nein Grafische Benutzeroberfläche (GUI)

306______________________________ Kapitel 9. Betriebssystemarchitektur

Daher werden nach diesen Standards geschriebene Programme auf allen POSIX-kompatiblen Systemen gleich ausgeführt. Allerdings haben die Standards teilweise nur beratenden Charakter. Einige der Standards sind sehr streng beschrieben, während andere die grundlegenden Anforderungen nur oberflächlich offenbaren. Häufig werden Softwaresysteme als POSIX-kompatibel deklariert, obwohl sie nicht als solche bezeichnet werden können. Die Gründe liegen im formalen Ansatz zur Implementierung der POSIX-Schnittstelle in verschiedenen Betriebssystemen. In Abb. Abbildung 9.1 zeigt ein typisches Implementierungsdiagramm für eine streng POSIX-kompatible Anwendung.

Reis. 9.1. Implementierungsdiagramm einer Anwendung, die strikt dem POSIX-Standard entspricht

Die Abbildung zeigt, dass das Programm ausschließlich POSIX-Bibliotheken verwendet, um mit dem Betriebssystem zu interagieren. 1 und die Standard-C-RTL-Bibliothek, in der nur 110 verschiedene Funktionen verwendet werden können, die ebenfalls vom POSIX-Standard beschrieben werden. 1.

Um die Leistung eines bestimmten Subsystems zu steigern oder proprietäre Technologien einzuführen, die den Anwendungsbereich der Anwendung auf die entsprechende Betriebsumgebung beschränken, werden bei der Programmierung leider häufig andere Funktionen verwendet, die nicht dem POSIX-Standard entsprechen.

Die Implementierungen des POSIX-Standards auf Betriebssystemebene variieren. Während die überwiegende Mehrheit der UNIX-Systeme zunächst den Spezifikationen des IEEE-Standards 1003.1-1990 entspricht, ist WinAPI nicht POSIX-kompatibel. Allerdings zur Unterstützung im Operationssaal Windows-System NT führte ein spezielles API-Modul zur Unterstützung des POSIX-Standards ein, das auf der Berechtigungsebene von Benutzerprozessen arbeitet. Dieses Modul ermöglicht die Konvertierung und Übertragung von Aufrufen von einem Benutzerprogramm zum Systemkernel und zurück und arbeitet mit dem Kernel über WinAPI. Andere mit WinAPI geschriebene Anwendungen können POSIX-Informationen über die Standard-E/A-Stream-Mechanismen stdin und stdout an Anwendungen übergeben.

Programmierbeispiele für verschiedene APIs____________________ 307

Programmierbeispiele für verschiedene APIs

Um die grundlegenden Unterschiede zwischen den API-Schnittstellen der gängigsten modernen Betriebssysteme für Personalcomputer deutlich zu machen, werfen wir einen Blick darauf einfachstes Beispiel, in dem Sie die Anzahl der Leerzeichen zählen müssen Textdateien, deren Namen in der Befehlszeile angegeben werden müssen. Betrachten wir zwei Versionen des Programms: für Windows (mit WinAPI) und für Linux (POSIX-API).

Da wir daran interessiert sind, mit parallelen Aufgaben zu arbeiten, gehen wir davon aus, dass bei der Ausführung des Programms für jede der in der Befehlszeile aufgeführten Dateien ein eigener Prozess oder Ausführungsthread (Aufgabe) erstellt wird, der parallel zu anderen Prozessen läuft (Threads), übernimmt die Aufgabe, Leerzeichen in „seiner“ Datei zu zählen. Das Ergebnis des Programms ist eine Liste von Dateien mit der Anzahl der jeweils gezählten Leerzeichen.

Besonderes Augenmerk sollte auf die Tatsache gelegt werden, dass die unten aufgeführten Implementierungen von Programmen zur Lösung dieses Problems nicht die einzig möglichen sind. Beide betreffenden Betriebssysteme verfügen über unterschiedliche Methoden für die Arbeit mit dem Dateisystem und die Verwaltung von Prozessen. IN in diesem Fall Es wird nur eine Option berücksichtigt, diese ist jedoch die typischste für die entsprechende API-Schnittstelle.

Um den Vergleich dieses (Listing 9.1) und der folgenden (Listing 9.2) Programme zu erleichtern und auch zu berücksichtigen, dass die Aufgabe für ihre Lösung keine Fensterschnittstelle benötigt, sondern nur die API-Aufrufe, die keinen Einfluss auf die haben Im Text werden grafische Benutzeroberflächen verwendet. Heutzutage kommt es natürlich selten vor, dass eine Anwendung nicht die Möglichkeiten der GUI nutzt, aber in unserem Fall erkennt man sofort den Unterschied in der Organisation des Parallelbetriebs der gestarteten Berechnungen.

Alexey Fedorchuk
2005

Eines der charakteristischen Merkmale der logischen Struktur des Dateisystems der Betriebssysteme der POSIX-Familie ist ihre hierarchische oder baumartige Organisation (obwohl der Baum, wie ich bereits sagte, etwas seltsam aussieht). Das heißt, es gibt keine Bezeichnungen (z. B. alphabetisch oder anders) für einzelne Medien und deren Abschnitte wie bei DOS oder Windows jeglicher Art: Sie sind alle in einer einzigen Struktur als Unterverzeichnisse des Hauptverzeichnisses enthalten. namens Wurzel. Verbindungsprozess Dateisysteme auf unabhängigen physischen Medien (und deren Partitionen) zum Stammverzeichnis des Dateibaums wird als Mount bezeichnet, und die Unterverzeichnisse, deren Inhalt sie umfassen, werden als Mount-Punkte bezeichnet.

Historisch gesehen hat Unix eine bestimmte Verzeichnisstruktur entwickelt, die im Allgemeinen bei den verschiedenen Mitgliedern dieser Familie sehr ähnlich ist, sich jedoch im Detail leicht unterscheidet. Insbesondere ist die Dateihierarchie in BSD-Systemen nahezu identisch und unterscheidet sich von der in Linux. Und in letzterem Fall gibt es erhebliche Unterschiede zwischen verschiedenen Verteilungen. Bis zu dem Punkt, dass die Struktur der Dateihierarchie zu den distributionsspezifischen Merkmalen gehört.

Dieser Sachverhalt macht es schwierig, plattformübergreifende Anwendungen zu schreiben. Und deshalb gibt es und entwickelt aktiv ein Projekt zur Standardisierung der Dateihierarchie – FHS (Filesystem Hierarchy Standard).

Das FHS-Projekt zielte ursprünglich darauf ab, die Verzeichnisstruktur zahlreicher Linux-Distributionen zu verschlanken. Später wurde es für andere Unix-ähnliche Systeme (einschließlich des BSD-Clans) angepasst. Und jetzt gibt es aktive (aber nicht sehr erfolgreiche) Bemühungen, es nicht nur dem Namen nach, sondern tatsächlich zum Standard für POSIX-Systeme zu machen.

Der FHS-Standard basiert auf zwei Grundprinzipien: einer klaren Trennung in der Dateihierarchie von freigegebenen und nicht freigegebenen Verzeichnissen einerseits und unveränderlichen und veränderlichen Verzeichnissen andererseits.

Der Kontrast zwischen freigegebenen und nicht freigegebenen Verzeichnissen ist auf die inhärent vernetzte Natur von Unix zurückzuführen. Das heißt, Daten, die sich auf den lokalen Computer beziehen (z. B. Konfigurationsdateien für seine Geräte), sollten sich in Verzeichnissen befinden, die von denen getrennt sind, deren Inhalte von anderen Computern im Netzwerk aus zugänglich sind, lokal oder global (ein Beispiel hierfür ist nicht nur der Benutzer). Daten, aber auch Programme).

Der wesentliche Unterschied zwischen unveränderlichen und veränderlichen Verzeichnissen lässt sich leicht anhand eines Beispiels erklären. Daher müssen dieselben allgemeinen Benutzerprogramme unveränderlicher Natur sein (oder vielmehr nur dem Systemadministrator zur Änderung zur Verfügung stehen, nicht jedoch dem Benutzer selbst, der sie bei seiner Arbeit verwendet). Gleichzeitig erzeugen diese Programme während ihres Betriebs nicht nur Datendateien, beispielsweise Texte oder Bilder (ihre variable Natur ist kommentarlos klar), sondern alle Arten von Dienstinformationen, wie Protokolldateien, temporäre Dateien usw wie). Diese sollten in Verzeichnissen gruppiert werden, die von den eigentlichen ausführbaren Dateien von Programmen, Bibliotheken, Konfigurationsdateien usw. getrennt sind, die für ihren Start erforderlich sind.

Trotz aktiver Förderung in vielen der gängigsten Linux-Distributionen hat FHS jedoch nicht den Status eines echten Standards erreicht. Es gibt viele Linux-Distributionen, die einige seiner Bestimmungen nicht nutzen. Und es korreliert nur teilweise mit der traditionellen Dateihierarchie von BSD-Systemen.

Und der Grund dafür ist, dass FHS einen weiteren Kontrast ignoriert, der für den Benutzer sehr wichtig ist: den Kontrast zwischen leicht wiederherstellbaren Teilen des Dateisystems und solchen seiner Komponenten, die schwer oder gar nicht wiederhergestellt werden können.

Das erste betrifft seltsamerweise das Basissystem selbst: Schließlich ist es im Falle eines tödlichen Absturzes nicht so schwierig, es vom Distributionsmedium neu zu installieren. Zu den schwer wiederherzustellenden Teilen des Dateisystems gehören natürlich Benutzerdaten: Selbst wenn sie regelmäßig gesichert werden (und wie viele Benutzer sind so vorsichtig?), wird das Ausrollen aus Archiven viel Zeit in Anspruch nehmen (und fast zwangsläufig mit sich bringen). einige Verluste).

Darüber hinaus würde ich in BSD-Systemen und quellbasierten Linux-Distributionen alles, was mit der Paketverwaltung zu tun hat, als schwer wiederherzustellende Verzeichnisse einstufen – den FreeBSD-Ports-Baum oder pkgsrc in NetBSD (und Systeme, die ihn ausgeliehen haben), ihre Entsprechungen in Linux-Distributionen, die tatsächlichen Quellen portierter Programme und auch die Quellcodes des Systems. Denn selbst wenn all dies im Distributionskit enthalten ist, werden diese Dateisystemkomponenten in der Regel vom Benutzer durch Synchronisierung über das Netzwerk mit den Projektservern auf dem neuesten Stand gehalten (ansonsten macht ihre Verwendung keinen Sinn). Und ihr Verlust wird sowohl vorübergehende (insbesondere bei einer Modemverbindung) als auch finanzielle Verluste (nur wenige Menschen sind glückliche Besitzer eines kostenlosen Internetzugangs) mit sich bringen.

Die strikte Einhaltung des Konzepts, gemeinsam genutzte und nicht gemeinsam genutzte, unveränderliche und unveränderliche, wiederherstellbare und nicht wiederherstellbare Verzeichnisse voneinander zu trennen, ermöglicht es, innerhalb einer einzigen baumartigen Dateihierarchie ihre einzelnen Zweige physisch – also in der Form – zu isolieren unabhängiger Dateisysteme, die sich auf isolierten Geräten befinden (Festplatten, Festplattenabschnitte, Slices, Partitionen usw.). Dafür gibt es viele Gründe – höhere Geschwindigkeit, höhere Zuverlässigkeit und einfach Bequemlichkeitserwägungen – aber darüber wollen wir jetzt nicht sprechen. Denn in im Moment Für uns zählt lediglich, dass diese Zweige des Dateibaums in das gesamte Dateisystem eingebunden werden müssen.

Ein typischer Satz von POSIX-Systemverzeichnissen

Tatsächlich ist es für den Betrieb unbedingt erforderlich, nur ein Dateisystem zu haben – dasjenige, das im Stammverzeichnis des Dateibaums gemountet ist (eine Art Analogon zum Weltbaum Yggdrassil). Das Stammverzeichnis und seine wesentlichen Zweige müssen ein einziges Dateisystem bilden, das sich auf einem Medium befindet – einer Festplatte, einer Festplattenpartition, einem Software- oder Hardware-RAID-Array oder einem logischen Volume im Sinne von LVM. Und es sollte alle zum Starten des Systems notwendigen Komponenten enthalten und im Idealfall nichts weiter.

Mit dem Befehl können Sie die Zusammensetzung des Stammverzeichnisses anzeigen

$ls -1/

was auf jedem POSIX-System einen bestimmten Mindestsatz an Gentleman-Verzeichnissen anzeigt:

Bin/ boot/ etc/ root/ sbin/

Sie enthalten alle Dateien, ohne die das System nicht existieren kann. Andere Verzeichnisse sehen etwa so aus:

Home/ mnt/ opt/ tmp/ usr/ var/

Sie a) sind nicht erforderlich (zumindest theoretisch – in der Praxis ist es schwierig, auf sie zu verzichten), b) nicht jeder von ihnen ist in allen Systemen und Distributionen vorhanden und c) jeder von ihnen kann (und ist es oft auch) – wenn Sie machen alles mit Bedacht) ) den Einhängepunkt seines eigenen Zweigs des Dateibaums.

Darüber hinaus gibt es in den meisten Fällen im Stammverzeichnis des Dateisystems POSIX-kompatibler Betriebssysteme zwei weitere Unterverzeichnisse:

Dev/proc/

Dies sind normalerweise die Einhängepunkte für virtuelle Dateisysteme – Geräte bzw. Prozesse (obwohl das Verzeichnis /dev, wenn kein Gerätedateisystem verwendet wird, eine Komponente des Root-Dateisystems sein muss. Auf Linux-Systemen schließlich in der Regel Im Stammverzeichnis des Dateibaums befindet sich außerdem ein /lib-Verzeichnis, das für die Hauptsystembibliotheken vorgesehen ist. Und bei Verwendung des udev-Mechanismus ist auch das /sys-Verzeichnis unvermeidlich, in dem das virtuelle Dateisystem sysfs gemountet wird.

Root-Dateisystem

Das Root-Dateisystem ist nicht gemeinsam genutzt (d. h. nicht dafür vorgesehen). teilen verschiedene Maschinen im Netzwerk) und unveränderbar (d. h. Änderungen daran können nur vom Systemadministrator vorgenommen werden, nicht jedoch von Benutzerprogrammen und insbesondere nicht von Benutzern). Darüber hinaus wird dringend davon abgeraten, darin Unterverzeichnisse zu erstellen, die über die im Standard vorgesehenen (und oben aufgeführten) hinausgehen.

Der Inhalt des Root-Dateisystems wird so ausgewählt, dass die Maschine auch während eines Notstarts (oder im Einzelbenutzermodus) starten und minimale Funktionalität beibehalten kann, wenn alle anderen Dateisysteme nicht gemountet sind (und dementsprechend ihre Zweige wie /usr oder /var sind möglicherweise nicht verfügbar.

Dementsprechend wird der Start der Maschine durch die Verzeichnisdateien /boot und /etc sichergestellt. Die erste enthält den Systemkernel – eine ausführbare Datei für „spezielle Zwecke“ – und alles, was zum Laden erforderlich ist: In Linux ist dies beispielsweise die Systemzuordnung (Datei /etc/System.map) und in FreeBSD – ladbar Kernel-Module. Manchmal befindet sich der Kernel jedoch direkt im Stammverzeichnis des Dateisystems, dann fehlt das Verzeichnis /boot möglicherweise ganz und das Verzeichnis /modules ist möglicherweise für Kernelmodule reserviert.

Das Verzeichnis /etc ist für systemweite Konfigurationsdateien gedacht, die die Startbedingungen bestimmen. Sein Inhalt hängt stark vom System (und bei Linux auch von der Distribution) ab, weshalb ich hier nicht darauf eingehen werde – ich werde mehr als einmal auf dieses Thema zurückkommen müssen.

Die minimal erforderliche Funktionalität wird durch den Inhalt der Verzeichnisse /bin und /sbin bereitgestellt – sie enthalten ausführbare Dateien der wichtigsten Benutzer- bzw. Systemprogramme, die Ihnen die Durchführung einer Reihe von Reparatur- und Rettungsmaßnahmen ermöglichen Bringen Sie die Maschine nach einem Ausfall wieder in die menschliche Form.

Die Verteilung von System- und Benutzerprogrammen in Unterverzeichnisse des Roots ist recht willkürlich. Keiner dieser Befehle ist wirklich dazu gedacht, Benutzerprobleme zu lösen. Es ist nur so, dass das Verzeichnis /bin Verwaltungsbefehle enthält, auf die ein normaler Benutzer von Zeit zu Zeit zugreift (oder zugreifen kann), und das Verzeichnis sbin für Befehle gedacht ist, von denen der Benutzer nichts wissen sollte. Und die er in den meisten Fällen mangels entsprechender Berechtigungen (zum Beispiel der erforderlichen Zugriffsrechte auf Gerätedateien) trotzdem nicht nutzen kann.

Um POSIX-Programme auszuführen (einschließlich der in den Verzeichnissen /bin und sbin gesammelten), benötigen Sie in der Regel Zugriff auf die Funktionen systemweiter Bibliotheken (hauptsächlich die Hauptbibliothek von glibc). Und deshalb (fast) ein unverzichtbarer Bestandteil des Stammverzeichnisses ist das Unterverzeichnis /lib, in dem sie gesammelt werden.

Unter Linux erfüllt das Verzeichnis /lib einen weiteren wichtigen Zweck – sein Unterverzeichnis (/lib/modules) enthält ladbare Kernelmodule (in FreeBSD ist ihr Platz das Verzeichnis /boot/kernel).

In FreeBSD befindet sich das /lib-Verzeichnis nicht im Root-Dateisystem – die entsprechenden Komponenten befinden sich hier in /usr/lib (siehe unten). Dies liegt daran, dass FreeBSD in der Vergangenheit wichtige systemweite Programme so erstellt hat, dass die von ihnen benötigten Bibliotheksfunktionen in ihre ausführbaren Dateien integriert waren (bekannt als statisches Linken, besprochen in Kapitel 14). Im FreeBSD-Zweig 5 sind Programme aus den Verzeichnissen /bin und /sbin dynamisch verknüpft, d. h. ohne das Verzeichnis /usr (und in Free ist dies fast immer ein separater Zweig des Dateisystems) funktionieren sie nicht . Um dies zu kompensieren, wird ein nicht standardmäßiges /restore-Verzeichnis bereitgestellt, das dieselben Programme enthält, jedoch statisch verknüpft ist (wie der Name des Verzeichnisses schon sagt, dient sein Inhalt nur der Notfallrettung).

Und schließlich /root . Dies ist das übliche Home-Verzeichnis des gleichnamigen Benutzers, also des Systemadministrators. Denn nein praktische Arbeit Das ist nicht der Fall (oder sollte es zumindest nicht sein), sein Inhalt sind lediglich die eigenen Konfigurationsdateien des Superusers (Befehls-Shell des Benutzers, Lieblingseditor usw.).

Zweig /usr

Historisch gesehen war das Verzeichnis /usr für Benutzerprogramme und Daten gedacht. Diese Funktionen sind jetzt auf die Verzeichnisse /usr/local und /home aufgeteilt (obwohl letzteres unter FreeBSD standardmäßig immer noch ein symbolischer Link zu /usr/home ist). Das Verzeichnis /usr ist nicht änderbar, sondern gemeinsam genutzt und dient als Repository für den Hauptteil von Anwendungsprogrammen und alles, was damit zusammenhängt – Quellcodes, Konfigurationsdateien, gemeinsam genutzte Bibliotheken, Dokumentation und dergleichen.

Die Zusammensetzung des /usr-Verzeichnisses unterscheidet sich erheblich zwischen BSD-Systemen und Linux. Im ersten Fall werden nur integrale Teile des Betriebssystems darin platziert (was in FreeBSD durch das Konzept der Distributionen vereint wird). Von Ports oder Paketen installierte Anwendungen werden im Unterverzeichnis /usr/local registriert, das einen separaten Zweig des Dateibaums darstellen kann.

Unter Linux dient das Verzeichnis /usr als Repository für alle Programme (und deren Komponenten), die standardmäßig in der Distribution enthalten sind. Und das Unterverzeichnis /usr/local ist normalerweise für Programme gedacht, die unabhängig aus Quellen kompiliert werden.

In jedem Fall ist die übliche Zusammensetzung des /usr-Verzeichnisses wie folgt (als Ausgabe des Befehls ls -1):

X11R6/ bin/ etc/ include/ lib/ libexec/ local/ sbin/ share/ src/

Wie bereits erwähnt, ist das Unterverzeichnis /usr/local ein separater Zweig des Dateibaums und wird daher separat betrachtet. Der Zweck anderer Verzeichnisse ist wie folgt:

• /usr/bin und /usr/sbin sind für ausführbare Dateien von Benutzer- und Systemprogrammen gedacht (hier ist die Grenze zwischen ihnen noch willkürlicher als im Fall des Stammverzeichnisses), deren Zweck über die Gewährleistung der Grundfunktion von hinausgeht das System;
• /usr/etc ist für Konfigurationsdateien einzelner Anwendungen;
• /usr/include enthält die sogenannten Header-Dateien, die zum Verknüpfen ausführbarer Dateien mit Bibliothekskomponenten erforderlich sind;
• /usr/lib und /usr/libexec sind Verzeichnisse für gemeinsam genutzte Bibliotheken, von denen Benutzeranwendungen abhängen;
• /usr/share – ein Container für eine Vielzahl sogenannter. Architekturunabhängige Komponenten: Hier können Sie Dokumentation in verschiedenen Formaten, Beispiele für Konfigurationsdateien, von Konsolenverwaltungsprogrammen verwendete Daten (Schriftarten, Tastaturlayouts) und Beschreibungen von Zeitzonen sehen;
• /usr/src – Verzeichnis für Quellcodes; Unter Linux werden hier normalerweise nur die Quellcodes der Systemkerne platziert, während in BSD-Klonen der gesamte Quellcodesatz des Komplexes abgelegt wird, der in FreeBSD als Distributionen bezeichnet wird. Grundsätzlich ist es nicht ratsam, hier Quellcodes von selbst zusammengestellten Programmen abzulegen;
• /usr/X11R6 – Verzeichnis für Komponenten des X-Window-Systems – ausführbare Dateien (/usr/X11R6/bin), Bibliotheken (/usr/X11R6/lib), Header (/usr/X11R6/include), Dokumentation (/usr/ X11R6/ Mann); X-Anwendungsdateien sollten hier nicht abgelegt werden (mit der möglichen Ausnahme von Fenstermanagern) – ihr Platz befindet sich je nach System in /usr, /usr/local oder /opt.

Darüber hinaus kann das Verzeichnis /usr die Unterverzeichnisse /usr/var und /usr/tmp enthalten – normalerweise symbolische Links zu den entsprechenden Zweigen des Stammverzeichnisses. Und in einigen Linux-Distributionen wird die wichtigste systemweite Dokumentation – Manpages (im Unterverzeichnis /usr/man) direkt in /usr abgelegt.

Schließlich enthält das Verzeichnis /usr auf BSD-Systemen und einigen quellbasierten Linux-Distributionen (z. B. Gentoo) ein Unterverzeichnis für das Paketverwaltungssystem – FreeBSD- und OpenBSD-Ports (/usr/ports), ihre Analoga auf anderen Systemen (/usr). /portage in Gentoo). Obwohl aus der Sicht der Befolgung des Buchstabens und Geistes des FHS-Standards (er selbst erwähnt kein Wort über Ports und ähnliche Systeme) ein logischerer Ort für ihre Platzierung das Verzeichnis /var wäre (siehe unten) - und Genau das geschieht in Distributionen wie CRUX und Archlinux.

Zweig /usr/local

Wie bereits erwähnt, ist der /usr/local-Zweig in Linux für Programme gedacht, die unabhängig aus dem Quellcode kompiliert werden (nicht in dieser Distribution enthalten). Und in FreeBSD dient es als Container für die meisten Benutzeranwendungen – fast alles, was über Distributionen hinausgeht und über Pakete oder Ports installiert wird. Dementsprechend folgt die Verzeichnisstruktur als Ganzes der des /usr-Zweigs (mit offensichtlichen Ausnahmen):

Bin/ etc/ include/ lib/ man/ sbin/ share/

Auch der Inhalt der Unterverzeichnisse ist ähnlich: ausführbare Programmdateien (/usr/local/bin und /usr/local/sbin), ihre Konfigurationen (/usr/local/etc), Bibliotheken, mit denen sie verknüpft sind, und ihre Header-Dateien (/usr/local/lib bzw. /usr/local/include ), Manpages (/usr/local/man) und alle möglichen architekturunabhängigen Dinge (/usr/local/share), einschließlich Dokumentation in anderen Formaten .

Zweigstelle/opt

Das Verzeichnis /opt wird vom FHS-Standard bereitgestellt, wird jedoch nicht in allen Linux-Distributionen verwendet und fehlt auf BSD-Systemen vollständig. Allerdings werden immer mehr Programme mit Blick auf eine Standardinstallation geschrieben.

Historisch gesehen war das /opt-Verzeichnis unter Linux für kommerzielle Anwendungen und alle Arten von Programmen nicht ganz kostenloser Natur gedacht. Heutzutage besteht sein Zweck darin, große autarke Softwarekomplexe wie die Qt-Bibliothek, KDE mit all seinen Komponenten und Anwendungen, OpenOffice.org und dergleichen zu hosten. Die Verzeichnisstruktur sollte wie folgt aussehen: /opt/pkg_name. So sieht es auf meinem System (Archlinux) aus:

$ ls -1 /opt gnome/ kde/ OpenOffice.org1.1.2/ qt/

Jedes der Unterverzeichnisse hat seine eigene interne Struktur:

$ ls -1 /opt/* /opt/gnome: bin/ lib/ man/ share/ /opt/kde: bin/ etc/ include/ lib/ share/ /opt/OpenOffice.org1.1.2: help/ LICENSE LICENSE. html-Programm/ README README.html setup@ share/ spadmin@ THIRDPARTYLICENSEREADME.html user/ /opt/qt: bin/ doc/ include/ lib/ mkspecs/ Phrasebooks/ Plugins/ Templates/ Übersetzungen/

Der Zweck der Unterverzeichnisse in /opt/pkg_name lässt sich anhand der Analogie zu /usr und /usr/local leicht erraten. Beispielsweise ist /opt/kde/bin für ausführbare Dateien des KDE-Systems und seiner Anwendungen, /opt/kde/etc für seine Konfigurationsdateien, /opt/kde/include für Header-Dateien, /opt/kde/lib ist für Bibliotheken und /opt/kde/share – für freigegebene Dateien, einschließlich Dokumentation. KDE hat keine Dokumentation im man-Format, aber wenn sie existiert, dann können Sie das Unterverzeichnis /opt/pkg_name/ sehen (wie im Fall von Gnome – ich habe es nicht installiert, das ist es, was Gimp und ähnliche Gtk-Anwendungen abgerufen haben). Mann .

Sie können sehen, dass die Struktur des /opt-Verzeichnisses von der historischen (und intern begründeten POSIX-Tradition) abweicht, ähnliche Komponenten in Verzeichnissen zusammenzufassen – ausführbare Dateien, Bibliotheken usw. Und bei einer großen Anzahl von darin installierten Programmen schafft es bestimmte Schwierigkeiten: Sie müssen entweder die Variable mit den Werten $PATH überladen, was einen schnellen Zugriff auf Befehle ermöglicht (die in Kapitel 12 besprochen werden), oder Sie müssen ein spezielles /opt/bin-Verzeichnis erstellen und darin symbolische Links zu ausführbaren Programmbinärdateien platzieren. Daher wird das /-Verzeichnis in einigen Linux-Distributionen (z. B. in CRUX) grundsätzlich nicht verwendet. Wie in allen BSD-Systemen ist es durchaus möglich, dass es besser ist.

/var-Zweig

Wie der Name schon sagt, dient das Verzeichnis /var dazu, veränderbare Dateien zu speichern, die während des normalen Betriebs verschiedener Programme generiert werden – Software-Caches (z. B. Browser), Protokolldateien, Druckerspooling und Mailsysteme. Postfächer, Beschreibungen laufender Prozesse usw. Insbesondere werden im Verzeichnis /var sogenannte Dumps abgelegt – Momentaufnahmen des RAM-Zustands, die während eines abnormalen Herunterfahrens erstellt werden, um die Ursachen dafür zu ermitteln. Eine Besonderheit all dieser Komponenten ist, dass sie während einer Arbeitssitzung veränderbar sind und dennoch beim Neustart des Systems erhalten bleiben müssen.

Die interne Struktur von /var variiert stark von System zu System, daher werde ich nicht näher auf die Details seiner Struktur eingehen. Ich möchte nur anmerken, dass dieses Verzeichnis ein logischer Ort für die Platzierung von Komponenten aller Arten portähnlicher Paketverwaltungssysteme ist, wie dies beispielsweise in der Archlinux-Distribution der Fall ist, wo das Unterverzeichnis /var/abs dafür reserviert ist (abs - Archlinux-Bausystem).

Verzeichnis /mnt

Das Verzeichnis /mnt ist zum Mounten temporär genutzter Dateisysteme vorgesehen, die sich in der Regel auf Wechselmedien befinden. In einem vollständig installierten System ist es normalerweise leer und seine Struktur ist in keiner Weise reguliert. Dem Benutzer steht es frei, darin Unterverzeichnisse für einzelne Medientypen anzulegen. Auf meinem System sind dies beispielsweise /mnt/cd, /mnt/dvd, /mnt/usb und /mnt/hd – für CDs, DVDs, Flash-Laufwerke und Wechselfestplatten.

In FreeBSD sind die Standardverzeichnisse zum Mounten von CDs und Disketten /cdrom und /floppy direkt im Stammverzeichnis. Was nicht ganz mit dem Standard übereinstimmt, aber auf seine Art logisch ist – das Stammverzeichnis enthält die Einhängepunkte von Geräten, die in einem beliebigen Computer vorhanden sind (z. B. eine CD-ROM) oder bis vor Kurzem vorhanden waren (ein Diskettenlaufwerk).

Filiale/Zuhause

Das /home-Verzeichnis soll Benutzer-Home-Verzeichnisse enthalten. Sein Inhalt ist in keiner Weise geregelt, aber normalerweise sieht er wie /home/(username1,...,username#) aus. Auf großen Systemen mit vielen Benutzern können die Home-Verzeichnisse jedoch gruppiert sein.

Das /home-Verzeichnis kann nicht nur die Home-Verzeichnisse realer, sondern auch einiger virtueller Benutzer enthalten. Wenn der Computer also als Web- oder FTP-Server verwendet wird, können Sie Unterverzeichnisse wie /home/www bzw. /home/ftp sehen.

Zweig /tmp

Das Einzige, worüber wir noch reden müssen, ist das Verzeichnis zum Speichern temporärer Dateien – /tmp. Sie werden wie /var-Komponenten generiert verschiedene Programme im Rahmen ihrer normalen Lebensaktivitäten. Im Gegensatz zu /var wird jedoch nicht erwartet, dass /tmp-Komponenten außerhalb der aktuellen Sitzung gespeichert werden. Außerdem alle Handbücher Systemadministration Es wird empfohlen, dieses Verzeichnis regelmäßig (z. B. beim Neustart des Computers) oder in regelmäßigen Abständen zu bereinigen. Daher ist es ratsam, Dateisysteme als /tmp im RAM zu mounten – tmpfs (in Linux) oder mfs (in FreeBSD). Dadurch wird nicht nur sichergestellt, dass der Inhalt beim Neustart gelöscht wird, sondern auch die Leistung verbessert, beispielsweise bei der Kompilierung von Programmen, deren temporäre Produkte nicht auf die Festplatte geschrieben, sondern in einem virtuellen Verzeichnis wie /tmp/obj abgelegt werden.

Auf vielen Systemen finden Sie Verzeichnisse wie /usr/tmp und /var/tmp. Dies sind normalerweise symbolische Links zu /tmp.

Strategie zur Partitionierung des Dateisystems

Zum Abschluss des Gesprächs über die Dateihierarchie sollte betont werden, dass garantiert ist, dass sich nur die im Absatz aufgeführten Verzeichnisse auf einem Dateisystem befinden (im übertragenen Sinne auf einer Festplattenpartition, obwohl dies nicht ganz korrekt ist). Root-Dateisystem. Alle anderen Verzeichnisse – /usr, /opt, /var, /tmp und natürlich /home – können Mountpunkte für unabhängige Dateisysteme auf separaten physischen Medien oder deren Partitionen darstellen.

Darüber hinaus in lokales Netzwerk Diese Verzeichnisse können sich durchaus auch auf unterschiedlichen Rechnern befinden. So kann ein Computer, der als Anwendungsserver fungiert, die im Netzwerk freigegebenen Verzeichnisse /usr und /opt enthalten, ein anderer – ein Dateiserver – kann alle Home-Verzeichnisse der Benutzer enthalten und so weiter.

Jetzt muss nur noch entschieden werden, welche Dateisysteme vom allgemeinen Dateibaum isoliert werden sollten und warum. Die Antwort auf diese Fragen hängt stark vom verwendeten Betriebssystem und im Fall von Linux auch von dessen Verbreitung ab. Dennoch können allgemeine Grundsätze zur Trennung von Dateisystemen skizziert werden. Aus diesem Grund sollten wir uns an den Kontrast zwischen unveränderlichen und veränderlichen Verzeichnissen einerseits und leicht wiederherstellbaren, schwer wiederherstellbaren und praktisch nicht wiederherstellbaren Daten andererseits erinnern. Machen wir diesen Versuch in Bezug auf den Desktop eines Benutzers – im Fall eines Servers werden die Berechnungen deutlich anders ausfallen.

Offensichtlich sollte sich das Root-Dateisystem, bestehend aus den Verzeichnissen /bin, /boot, /etc, /root, /sbin, mit Daten, die leicht vom Distributionsmedium wiederhergestellt werden können und praktisch unveränderlich sind, auf einer isolierten Festplattenpartition befinden . Unter Linux sollte dies auch ein /lib-Verzeichnis enthalten. Bei der Verwendung von GRUB als Bootloader (unabhängig vom Betriebssystem) empfiehlt es sich hingegen, das /boot-Verzeichnis auf einer separaten Partition zu platzieren.

In alten Quellen zu Linux können Sie einen weiteren Grund für die Zuweisung einer Partition für das /boot-Verzeichnis und ganz am Anfang der Festplatte lesen: aufgrund der Unmöglichkeit, den Kernel durch das Lilo-Programm von einer Zylindernummer über 1023 zu laden . In modernen Versionen von Bootloadern gibt es keine derartigen Einschränkungen. Wenn jedoch bereits eine Partition für /boot erstellt wird, ist es sinnvoll, diese als erste auf der Festplatte zu erstellen und die Swap-Partition direkt dahinter zu platzieren: Dies erhöht die Leistung beim Auslagern um fünf Cent.

Und noch etwas aus dem Bereich der Geschichte: Die Anforderung, dass die Root- und Boot-Partition primär sein müssen, wurde ebenfalls vor langer Zeit entfernt. Und diese Dateisysteme passen möglicherweise durchaus auf logische Partitionen innerhalb der erweiterten Partition.

Ebenso klar ist, dass die veränderbaren Zweige des Dateisystems – die Verzeichnisse /var und /tmp – aus der Root-Partition verschoben werden müssen. Darüber hinaus empfiehlt es sich bei Letzterem, wie bereits mehrfach erwähnt, generell, es in einem Dateisystem im RAM (tmpfs oder mfs) zu platzieren. Falls das /var-Verzeichnis Unterverzeichnisse für portähnliche Paketverwaltungssysteme wie /var/abs , /var/cache/pacman/src und /var/cache/pacman/pkg in Archlinux enthält, sollten diese ebenfalls separate Dateisysteme bilden

Jetzt das Verzeichnis /usr, das entweder die Komponenten des Basissystems (wie in BSD) oder den Großteil der Benutzeranwendungen (wie in den meisten Linux-Distributionen) enthält. Es enthält leicht wiederherstellbare Daten und sollte, um fair zu sein, praktisch unveränderlich sein und verdient daher natürlich die Zuweisung in einen separaten Abschnitt. Darüber hinaus empfiehlt es sich, aus seiner Zusammensetzung einerseits die Unterverzeichnisse /usr/X11R6 und /usr/local, andererseits Unterverzeichnisse für portähnliche Paketverwaltungssysteme zu isolieren: /usr/ports, /usr/pkgsrc und /usr/pkg in BSD-Systemen, /usr/portages unter Gentoo Linux und so weiter. Darüber hinaus sollte Letzteres in Unterverzeichnisse unterteilt werden, um beim Erstellen von Ports aus dem Netzwerk heruntergeladene Quellen zu platzieren – /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles und dergleichen.

In BSD-Systemen ist es außerdem sinnvoll, aus dem Verzeichnis /usr die Unterverzeichnisse /usr/src und /usr/obj auszuwählen, die den Quellcode der Grundkomponenten (einschließlich des Kernels) und Zwischenprodukte ihrer Kompilierung enthalten, die als a Ergebnis der Prozeduren make buildworld und make buildkernel .

Und schließlich muss das Verzeichnis /home, das veränderbare und oft nicht wiederherstellbare Daten enthält, aus dem Stammverzeichnis der Dateihierarchie entfernt werden. Außerdem versuche ich immer, es entweder auf einem separaten Slice (in BSD) oder auf der primären Partition (in Linux) zu platzieren.

Das vorgeschlagene Schema zur Trennung von Dateisystemen mag unnötig kompliziert erscheinen. Es gewährleistet jedoch die Isolierung leicht wiederherstellbarer, schwer wiederherstellbarer und nicht wiederherstellbarer Daten, was im Notfall die Neuinstallation des Systems und sogar die Migration von System zu System erleichtert.

Sein zusätzlicher Vorteil besteht darin, dass Sie unter Linux für einzelne Zweige des Dateibaums je nach Art der darauf befindlichen Daten ein physikalisch optimales Dateisystem auswählen können. Beispielsweise macht es für die /boot-Partition keinen Sinn, etwas anderes als Ext2fs zu verwenden. Normalerweise wird empfohlen, die Root-Partition im zuverlässigen und kompatibelsten Ext3fs zu formatieren. Für Verzeichnisse mit einer großen Anzahl kleiner Dateien, wie z. B. /var/abs in Archlinux, /usr/portages in Gentoo, empfiehlt sich die Verwendung von ReiserFS: Schließlich ist der geschickte Umgang mit kleinen Dateien sein Profil. Und im /home-Verzeichnis, in dem riesige Multimediadateien erscheinen können (und das selbst normalerweise sehr groß ist), kann XFS nützlich sein (obwohl ReiserFS hier, wie Messungen zeigen, ganz ordentlich aussieht). Solche Maßnahmen können dazu beitragen, sowohl die Zuverlässigkeit der Datenspeicherung als auch die Geschwindigkeit von Dateivorgängen zu verbessern.

Benutzer von BSD-Betriebssystemen sind alternativlos an FFS-Dateisysteme gebunden. Allerdings haben sie auch Handlungsspielraum. Erstens durch Variation der Block- und Fragmentgrößen einzelner Dateisysteme, was entweder zur Leistung von Festplattenoperationen oder zur Einsparung von Festplattenspeicher beiträgt. Und zweitens können einige Zweige des Dateibaums (z. B. /tmp oder /usr/obj) entgegen den Empfehlungen sicher im rein asynchronen Modus gemountet werden, was zu einer Leistungssteigerung um ein oder zwei Prozent führt.

- (IPAEng|ˈpɒzɪks) oder Portable Operating System Interface cite web | Titel = POSIX | URL = http://standards.ieee.org/regauth/posix/ | Arbeit = Standards | editor = IEEE] ist der Sammelname einer Familie verwandter Standards, die von der IEEE ... Wikipedia spezifiziert werden

POSIX- Es handelt sich um den Namen einer Familie von Standards, die seit 1988 vom Institute of Electrical and Electronics Engineers erstellt und nach IEEE 1003 benannt wurde. Diese Standards sind durch ein Standardisierungsprojekt für Logik-APIs entstanden, das für … … Wikipédia auf Französisch bestimmt ist

Posix- Es handelt sich um den Namen einer Familie von Standards, die seit 1988 von der IEEE definiert und nach IEEE 1003 benannt wurde. Diese Standards sind in einem Projekt zur Standardisierung der API von Logiken entstanden, die auf Systemvarianten von … … Wikipédia auf Französisch funktionieren sollen

POSIX- es ist die Abkürzung für Portable Operating System Interface; Die X-Version von UNIX basiert auf der API-Identität. Der Termin wurde von Richard Stallman als Reaktion auf die Anforderungen des IEEE angenommen, der einen Namen leicht aufzeichnen konnte. Eine Übersetzung … Wikipedia Español

POSIX- , 1986 im Standard 1003.1 der IEEE niedergelegte Spezifikation für Zugriffe auf Systemfunktionen unter Unix. Sowohl Unix Sy…Universal-Lexikon

POSIX- Standardstatus T sritis informatika apibrėžtis Standardų groupė, apibrėžianti operacinės sistemos sąsajas tarp joje veikiančių programų at tarnybų. Pirmuosius standartus sukūrė Elektros ir elektronikos inžinierių institutas (IEEE) Linux… … Enciklopedinis kompiuterijos žodynas

POSIX- Es handelt sich um die Abkürzung für Portable Operating System Interface, die X von UNIX mit der Bedeutung der API-Herenschaft verbindet (übersetzt als auf UNIX basierendes Portable Operating System). Es ist eine Familie von System-Lamadas… … Enciclopedia Universal

POSIX- (Portable Betriebssystemschnittstelle basierend auf UniX) n. Sammlung von Standards für Betriebssysteme, die auf Unix (Computern) basieren ... Englisches zeitgenössisches Wörterbuch

POSIX

Posix- Das Portable Operating System Interface (POSIX [ˈpɒsɪks]) ist ein gemeinsam von der IEEE und der Open Group für Unix entwickeltes standardisiertes Application Programming Interface, das die Schnittstelle zwischen Application und dem… … Deutsch Wikipedia

Bücher

• , Stephen A. Rago, W. Richard Stevens. „UNIX. Professional Programming“ ist ein ausführliches Nachschlagewerk, das professionellen C-Programmierern seit 20 Jahren dabei hilft, ausschließlich...
• UNIX. Professionelle Programmierung von Stevens W. Richard, Rago Steven A. Dieses Buch erfreut sich zu Recht großer Beliebtheit bei ernsthaften Programmierern auf der ganzen Welt, da es die wichtigsten und praktischsten Informationen zur Verwaltung von UNIX- und Linux-Kerneln enthält. Ohne diese...

Der Kurs behandelt den Mobile Operating System Interface Standard (POSIX) sowie Techniken und Methoden zur Programmierung von Anwendungen auf Basis dieses Standards, erläutert anhand zahlreicher Beispiele. Es werden Fragen der Programmierung von Multiprozesssystemen und der Interaktion von Anwendungen innerhalb verteilter Konfigurationen behandelt. Die Sicherstellung der Mobilität (Portabilität) von Software ist eine Aufgabe von außerordentlicher Bedeutung und Komplexität; Heutzutage bedarf dieser Umstand kaum einer langen Begründung. Eine der allgemein akzeptierten Möglichkeiten zur Verbesserung der Softwareportabilität ist die Standardisierung der Anwendungsumgebung: der bereitgestellten Softwareschnittstellen, Dienstprogramme usw. Auf der Ebene der Systemdienste wird eine solche Umgebung durch den POSIX-Standard (Portable Operating System Interface – mobile Betriebssystemschnittstelle) beschrieben; Der Name wurde vom berühmten Spezialisten und Gründer der Free Software Foundation, Richard Stallman, vorgeschlagen.

Der Kurs untersucht seine modernste Version in der Fassung von 2003, die als „Triple-Standard“ bezeichnet werden kann, nämlich den IEEE Std 1003.1-Standard, den Open Group Technical Standard und, was für uns am wichtigsten ist, den internationalen Standard ISO/IEC 9945 Die Hauptaufgabe dieses Kurses besteht darin, die Techniken und Methoden zur Verwendung standardisierter Dienstprogramme und Funktionen zu verstehen. Das Ziel bestand nicht darin, den Standard neu zu erzählen und alle Feinheiten der Betriebssystemimplementierung, alle möglichen Fehlercodes usw. hervorzuheben. Das Wichtigste ist unserer Meinung nach, den Geist des Standards zu spüren und zu lernen, die ihm innewohnenden Fähigkeiten mobil zu nutzen. Unter der Annahme, dass der Leser C spricht, haben wir weder die Syntax noch die Funktionen der Lehrbuchbibliothek berücksichtigt. Was die Standardbefehlssprache und ihren Interpreter betrifft, wird dieses Thema ausführlicher behandelt, obwohl viele praktizierende Programmierer lieber andere Interpreter verwenden. Einen bedeutenden Platz – sowohl im Umfang als auch in der Rolle – nehmen Programmbeispiele ein. Viele Bestimmungen des Standards (z. B. zur Behandlung von Fehlersituationen) sind nicht im Haupttext, sondern in den entsprechenden Beispielen aufgeführt. Letztere wurden, wann immer möglich, auf mehreren Hardware- und Softwareplattformen kompiliert und ausgeführt oder einen anderen Abschluss, behaupten, den POSIX-Standard einzuhalten. Allerdings sind Versehen natürlich möglich. Wir sind dankbar für alle Kommentare und Anregungen, die sich sowohl auf den gesamten Kurs als auch auf einzelne Programmbeispiele beziehen.

Entstehungsgeschichte und aktueller Stand des POSIX-Standards.

Die Sicherstellung der Mobilität (Portabilität) von Software ist eine Aufgabe von außerordentlicher Bedeutung und Komplexität; In unserer Zeit bedarf dieser Umstand kaum noch einer ausführlichen Begründung. Eine der allgemein akzeptierten Möglichkeiten zur Verbesserung der Softwareportabilität ist die Standardisierung der Anwendungsumgebung: bereitgestellte Softwareschnittstellen, Dienstprogramme usw. Auf der Ebene der Systemdienste wird eine solche Umgebung durch den POSIX-Standard (Portable Operating System Interface – mobile Betriebssystemschnittstelle) beschrieben; Der Name wurde vom berühmten Spezialisten und Gründer der Free Software Foundation, Richard Stallman, vorgeschlagen.

Titelblatt.
Ausgabedaten.
Vorlesung 1. Grundlegende Konzepte und Ideen des POSIX-Standards.
Vorlesung 2. Shell-Sprache.
Vorlesung 3. Dienstprogramme und Funktionen, die dem Konzept „Benutzer“ dienen.
Vorlesung 4. Dateisystemorganisation.
Vorlesung 5. Dateieingabe/-ausgabe.
Vorlesung 6. Werkzeuge zur Verarbeitung strukturierter Daten.
Vorlesung 7. Prozesse.
Vorlesung 8. Werkzeuge zur Interprozesskommunikation.
Vorlesung 9. Gemeinsame Terminalschnittstelle.
Vorlesung 10. Untersuchung von Hosteigenschaften und deren Verwendung in Anwendungen.
Vorlesung 11. Netzwerk-Tools.
Vorlesung 12. Zeit und die Arbeit damit.
Vorlesung 13. Sprachliches und kulturelles Umfeld.
Vorlesung 14. Fazit.
Referenzen.

Kostenloser Download E-Book in einem praktischen Format, sehen und lesen Sie:
Laden Sie das Buch „Programming in the POSIX standard, part 1“, Galatenko V.A., 2016 – fileskachat.com, schnell und kostenlos herunter.