Wenn Sie zwei Betriebssysteme installiert haben, Windows und Linux, möchten Sie wahrscheinlich direkt von Windows aus auf Partitionen eines kostenlosen Betriebssystems gespeichert werden, ohne den Computer neu starten zu müssen.

Leider gibt es in Windows keine Unterstützung für Linux-Betriebssystempartitionen. Aber vergeblich. Es scheint mir, dass dies werden könnte nette Geste von Microsoft.

Der Kern des Problems besteht darin, dass Windows das NTFS-Dateisystem verwendet und Linux über eine eigene Art der Dateiorganisation verfügt, das erweiterte Dateisystem. letzte Version welches die Seriennummer 4 hat.

Linux ist benutzerfreundlicher als seine kommerzielle Schwester: Linux unterstützt standardmäßig das Windows NTFS-Dateisystem. Natürlich können Sie Linux nicht auf einer NTFS-Partition installieren, aber Sie können Daten von einer solchen Partition lesen und schreiben.

Ext2 IFS

Ext2 IFS unterstützt die Windows NT4.0/2000/XP/2003/Vista/2008-Versionen x86 und x64 und ermöglicht Ihnen, den Inhalt von Linux-ext2-Partitionen anzuzeigen und auch darauf zu schreiben. Das Dienstprogramm installiert den Systemtreiber ext2fs.sys, der erweitert wird Windows-Funktionen und beinhaltet volle Ext2-Unterstützung: Ext2-Partitionen werden Laufwerksbuchstaben zugewiesen und darauf befindliche Dateien und Ordner werden in den Dialogen aller Anwendungen, beispielsweise im Explorer, angezeigt.

Ext2 FSD

Ext2 FSD – kostenloser Treiber Für Windows-Systeme(2K/XP/VISTA/7-Versionen x86 und x64). Wie das vorherige Dienstprogramm, das im Wesentlichen auch ein Treiber ist, bietet es vollständige Unterstützung für das ext2-Dateisystem in Windows.

LTOOLS – eine Reihe von Dienstprogrammen Befehlszeile, mit dem Sie von einem Computer unter DOS oder Windows aus Daten auf/von Linux ext2-, ext3- und ReiserFS-Partitionen (Standard-Linux-Dateisysteme) lesen und schreiben können.

Es gibt eine Version des Programms mit einer grafischen Shell (geschrieben in Java) – LTOOLSgui, sowie eine Version mit einer grafischen Shell, geschrieben in .

Ext2Read

Das Dessert ist wie immer das leckerste.

Ext2Read ist ein Dienstprogramm vom Typ Dateimanager, mit dem Sie ext2/ext3/ext4-Partitionen sowohl anzeigen als auch darauf schreiben können. Es unterstützt LVM2 und, was es von anderen Programmen in diesem Test unterscheidet, das ext4-Dateisystem. Integrierte Unterstützung für rekursives Verzeichniskopieren.

Und hier ist das zweite Dessert. Zunächst hieß es, eine gute Geste von Microsoft sei es, die Unterstützung von Linux-Partitionen in Windows standardmäßig zu aktivieren.

Die Geste erfolgte dennoch zum 20-jährigen Linux-Jubiläum. Überzeugen Sie sich selbst.

Das ist alles. Vielen Dank für Ihre Aufmerksamkeit. Ich werde die Maikäfer bekämpfen. Davon gibt es diesen Frühling so viele. 🙂

Jetzt beschreiben wir das beliebteste Linux-Festplattendateisystem – ext2. Die erste Version von Linux verwendete das MINIX 1-Dateisystem, das Folgendes hatte Kurznamen Dateien und die maximale Dateigröße beträgt 64 MB. Das Dateisystem MINIX 1 wurde schließlich durch das erste erweiterte Dateisystem ext ersetzt, das längere Dateinamen und größere Dateigrößen ermöglichte. Aufgrund seiner geringen Effizienz (im Hinblick auf die Leistung) wurde das ext-System durch sein bis heute weit verbreitetes Nachfolgesystem ext2 ersetzt.

Die ext2-Festplattenpartition enthält das in Abb. gezeigte Dateisystem. 10.17-Layout. Block 0 wird vom Linux-System nicht verwendet und enthält Code zum Booten des Computers. Nach Block 0 wird die Plattenpartition in Blockgruppen unterteilt (ohne Berücksichtigung der Grenzen der Plattenzylinder). Jede Gruppe ist wie folgt organisiert.

Der erste Block ist der Superblock, der Informationen über das Dateisystemlayout speichert, einschließlich der Anzahl der I-Nodes, der Anzahl der Festplattenblöcke und des Anfangs der Liste der freien Festplattenblöcke (normalerweise mehrere hundert Elemente). Darauf folgt ein Gruppendeskriptor, der Informationen über den Speicherort der Bitmaps, die Anzahl der freien Blöcke und I-Nodes in der Gruppe sowie die Anzahl der Verzeichnisse in der Gruppe enthält. Diese Informationen sind wichtig, da das ext2-Dateisystem versucht, Verzeichnisse gleichmäßig auf der Festplatte zu verteilen.

Zwei Bitmaps verfolgen freie Blöcke und freie I-Nodes (dies ist ebenfalls vom MINIX 1-Dateisystem übernommen und unterscheidet sich von den meisten UNIX-Dateisystemen, die eine Liste für freie Blöcke verwenden). Die Größe jeder Bitmap beträgt einen Block. Bei einer Blockgröße von 1 KB begrenzt dieses Schema die Blockgruppengröße auf 8192 Blöcke und 8192 I-Nodes. Die erste Zahl stellt eine echte Einschränkung dar, die zweite jedoch praktisch nicht. Bei 4-KB-Blöcken sind die Zahlen viermal größer.

Dann werden die i-Nodes selbst lokalisiert. Sie sind von 1 bis zu einem bestimmten Maximum nummeriert. Die Größe jedes I-Nodes beträgt 128 Byte und er beschreibt genau eine Datei. Der I-Node enthält Abrechnungsinformationen (einschließlich aller vom Stat-Aufruf zurückgegebenen Informationen, der sie einfach vom I-Node übernimmt) sowie genügend Informationen, um alle Festplattenblöcke zu finden, die die Dateidaten enthalten.

Den I-Nodes folgen Datenblöcke. Alle Dateien und Verzeichnisse werden hier gespeichert. Wenn eine Datei oder ein Verzeichnis aus mehr als einem Block besteht, müssen diese Blöcke auf der Festplatte nicht zusammenhängend sein. In Wirklichkeit die Blöcke große Datei, wird höchstwahrscheinlich über die gesamte Festplatte verteilt sein.

Die den Verzeichnissen entsprechenden I-Nodes sind über alle Gruppen von Festplattenblöcken verteilt. Ext2 versucht, reguläre Dateien in derselben Blockgruppe wie das übergeordnete Verzeichnis und Datendateien im selben Block wie der I-Node zu platzieren Quelldatei(vorausgesetzt, es ist dort genügend Platz). Diese Idee wurde dem Berkeley Fast File System (McKusick et al., 1984) entlehnt. Bitmaps werden verwendet, um schnelle Zuordnungsentscheidungen zu treffen

Platz für neue Dateisystemdaten.

Wenn neue Dateiblöcke zugewiesen werden, weist ext2 außerdem mehrere (acht) zusätzliche Blöcke derselben Datei vorab zu (um die Dateifragmentierung aufgrund zukünftiger Schreibvorgänge zu minimieren). Dieses Schema verteilt das Dateisystem über die gesamte Festplatte. Das hat sie auch gute Leistung(aufgrund seiner Tendenz, zusammenhängend zu sein und die Fragmentierung zu verringern).

Um auf eine Datei zuzugreifen, müssen Sie zunächst einen der Linux-Systemaufrufe (z. B. open) verwenden, bei dem Sie den Pfad zur Datei angeben müssen. Dieser Pfad wird analysiert und die darin enthaltenen Verzeichnisse werden extrahiert. Wenn ein relativer Pfad angegeben ist, beginnt die Suche im aktuellen Prozessverzeichnis, andernfalls im Stammverzeichnis. In jedem Fall ist der I-Node für das erste Verzeichnis leicht zu finden: Es gibt einen Zeiger darauf im Prozessdeskriptor oder (im Fall des Root-Verzeichnisses) wird er in einem bestimmten Block auf der Festplatte gespeichert.

Das Verzeichnis erlaubt Dateinamen mit bis zu 255 Zeichen (Abbildung 10.18). Jedes Verzeichnis besteht aus einer Reihe von Festplattenblöcken (sodass das Verzeichnis atomar auf die Festplatte geschrieben werden kann). In einem Verzeichnis sind die Elemente für Dateien und Verzeichnisse in unsortierter Reihenfolge (jedes Element folgt unmittelbar dem vorherigen). Elemente können Blockgrenzen nicht überschreiten, daher befindet sich am Ende jedes Plattenblocks normalerweise eine Reihe ungenutzter Bytes.

Jeder Verzeichniseintrag in Abb. 10.18 besteht aus vier Feldern fester Länge und einem Feld variabler Länge. Das erste Feld ist die I-Node-Nummer, die 19 für Colossal, 42 für Voluminous und 88 für Bigdir beträgt. Als nächstes folgt das Feld rec_len, das die Größe des gesamten Verzeichniseintrags in Bytes angibt (möglicherweise zusammen mit zusätzlichen Füllbytes nach dem Namen). Dieses Feld ist erforderlich, um den nächsten Eintrag zu finden (falls der Dateiname mit einer unbekannten Anzahl von Bytes aufgefüllt ist). In der Abbildung ist dieses Feld durch einen Pfeil gekennzeichnet. Dann gibt es ein Feld vom Typ Datei, Verzeichnis usw. Das letzte Feld fester Länge enthält die Länge des Dateinamens in Bytes (8, 10 und 6 für). dieses Beispiel). Schließlich gibt es noch den Dateinamen selbst, der mit einem Nullbyte endet und bis zur 32-Bit-Grenze aufgefüllt wird. Es können weitere Füllbytes folgen.

In Abb. Abbildung 10.18b zeigt dasselbe Verzeichnis, nachdem der Eintrag für voluminous entfernt wurde. Alles, was dies im Verzeichnis bewirkt, besteht darin, die Zahl im Feld „Eintragsgröße“ der vorherigen Datei kolossal zu erhöhen und die Bytes des Verzeichniseintrags für Remote-Datei voluminös werden zu Platzhaltern für den ersten Eintrag. Diese Bytes können später beim Erstellen einer neuen Datei zum Schreiben verwendet werden.

Da Verzeichnisse linear durchsucht werden, kann die Suche nach einem Eintrag am Ende eines großen Verzeichnisses lange dauern. Daher verwaltet das System einen Cache der zuletzt aufgerufenen Verzeichnisse. Der Cache wird anhand des Dateinamens durchsucht, und wenn er gefunden wird, ist eine aufwendige lineare Suche nicht mehr erforderlich. Für jede Pfadkomponente wird ein Dentry-Objekt in den Verzeichniseintragscache eingegeben, und (über seinen I-Node) wird das Verzeichnis nach nachfolgenden Pfadeinträgen durchsucht (bis der tatsächliche I-Node der Datei gefunden wird).

Um beispielsweise eine Datei zu finden, die durch einen absoluten Pfad angegeben ist (z. B. /usr/ast/file), müssen Sie die folgenden Schritte ausführen. Zuerst findet das System das Stammverzeichnis, das normalerweise I-Node Nummer 2 verwendet (insbesondere, wenn I-Node Nummer 1 für den Umgang mit fehlerhaften Blöcken reserviert ist). Es platziert das entsprechende Element im Verzeichniselement-Cache (für zukünftige Suchvorgänge im Stammverzeichnis). Anschließend wird das Stammverzeichnis nach der Zeichenfolge „usr“ durchsucht, um die I-Node-Nummer für das Verzeichnis /usr zu erhalten (das auch für die Verzeichniseinträge zwischengespeichert wird). Dieser I-Node wird dann gelesen und Festplattenblöcke werden von ihm abgerufen, sodass Sie das Verzeichnis /usr lesen und darin nach der Zeichenfolge „ast“ suchen können. Sobald das entsprechende Element gefunden ist, kann daraus die I-Node-Nummer für das Verzeichnis /usr/ast ermittelt werden. Mit dieser I-Node-Nummer kann dieser gelesen und Verzeichnisblöcke gefunden werden. Schließlich suchen wir nach „Datei“ und finden die I-Node-Nummer. Somit ist die Verwendung eines relativen Pfades nicht nur komfortabler für den Benutzer, sondern reduziert auch den Arbeitsaufwand für das System.

Wenn die Datei verfügbar ist, ruft das System die I-Node-Nummer ab und verwendet sie als Index in der I-Node-Tabelle (auf der Festplatte), um den entsprechenden I-Node zu finden und ihn in den Speicher einzulesen. Dieser I-Node wird in einer I-Node-Tabelle platziert, einer Kernel-Datenstruktur, die alle I-Nodes für aktuell geöffnete Dateien und Verzeichnisse enthält. Das I-Node-Elementformat muss (mindestens) alle Felder enthalten, die der Stat-Systemaufruf zurückgibt, damit der Stat-Aufruf funktioniert (siehe Tabelle 10.10). In der Tabelle Abbildung 10.13 zeigt einige der Felder der I-Node-Struktur, die im Linux-Dateisystem unterstützt werden. Die eigentliche I-Node-Struktur enthält viel mehr Felder, da dieselbe Struktur zur Darstellung von Verzeichnissen, Geräten und anderen speziellen Dateien verwendet wird. Die I-Node-Struktur enthält auch Felder, die für die zukünftige Verwendung reserviert sind. Die Geschichte hat gezeigt, dass ungenutzte Teile nicht lange herumliegen.

Sehen wir uns nun an, wie das System die Datei liest. Sie erinnern sich, dass ein typischer Bibliotheksprozeduraufruf zum Auslösen des Lesesystemaufrufs wie folgt aussieht:

n = read(fd, buffer, nbytes);

Wenn der Kernel die Kontrolle übernimmt, braucht er zunächst nur diese drei Parameter und die Informationen in seinen internen Tabellen (die sich auf den Benutzer beziehen). Eines der Elemente dieser internen Tabellen ist ein Array von Dateideskriptoren. Es wird durch Dateideskriptoren indiziert und enthält ein Element pro geöffneter Datei (bis zu einer maximalen Anzahl, der Standardwert ist normalerweise 32).

Die Idee besteht darin, mit diesem Dateideskriptor zu beginnen und mit dem entsprechenden Knoten zu enden. Schauen wir uns ein mögliches Schema an: Setzen Sie einen Zeiger auf einen Knoten in der Dateideskriptortabelle. Trotz der Einfachheit, diese Methode(leider) funktioniert nicht. Das Problem ist folgendes. Jeder Dateideskriptor muss über einen zugehörigen Dateizeiger verfügen, der das Byte in der Datei angibt, bei dem der nächste Lese- oder Schreibvorgang beginnt. Wo soll dieser Zeiger gespeichert werden? Eine Möglichkeit besteht darin, es in der Knotentabelle zu platzieren. Dieser Ansatz funktioniert jedoch nicht, wenn mehrere unabhängige Prozesse gleichzeitig dieselbe Datei öffnen, da jeder Prozess seinen eigenen Zeiger haben muss.

Die zweite Lösung besteht darin, den Zeiger in der Dateideskriptortabelle zu platzieren. In diesem Fall hat jeder Prozess, der eine Datei öffnet, seine eigene Position in der Datei. Leider funktioniert auch dieses Schema nicht, aber der Grund für das Scheitern ist in diesem Fall nicht so offensichtlich und hängt mit der Art der Dateifreigabe im Linux-System zusammen. Betrachten Sie Shell-Skript 5, das aus zwei Befehlen (p1 und p2) besteht, die nacheinander ausgeführt werden müssen. Wenn das Skript über die Befehlszeile aufgerufen wird

Dann wird erwartet, dass Befehl p1 seine Ausgabe in die Datei x schreibt, und dann schreibt Befehl p2 seine Ausgabe ebenfalls in die Datei x, beginnend dort, wo Befehl p1 aufgehört hat.

Wenn die Shell den Prozess p1 startet, ist die Datei als etwas anderes als 0. Dies ist genau das, was passieren wird, wenn die Position in der Datei in der Dateideskriptortabelle gespeichert ist) und der Wert, bei dem pi angehalten hat.

Wie das geht, zeigt Abb. 10.19. Der Trick besteht darin, eine neue Tabelle einzuführen – die Beschreibungstabelle Dateien öffnen(Dateibeschreibungstabelle öffnen) – zwischen der Dateideskriptortabelle und der I-Node-Tabelle und speichert den Zeiger auf die Datei (sowie das Lese-/Schreibbit) darin. In der Abbildung ist der übergeordnete Prozess die Shell, und der untergeordnete Prozess ist zuerst der Prozess pi und dann der Prozess p2. Wenn die Shell den Prozess pi erstellt, ist seine Benutzerstruktur (einschließlich der Dateideskriptortabelle) eine exakte Kopie derselben Shellstruktur, sodass beide Zeiger auf dieselbe geöffnete Dateideskriptortabelle enthalten. Wenn der Prozess pi beendet wird, verweist der Dateideskriptor der Shell weiterhin auf die Beschreibungstabelle der geöffneten Datei, die die Position des Prozesses p1 in der Datei enthält. Wenn die Shell nun den Prozess p2 erstellt, erbt der neue untergeordnete Prozess automatisch die Dateiposition, ohne dass entweder der neue Prozess oder die Shell den aktuellen Wert dieser Position kennen müssen.

Wenn ein externer Prozess eine Datei öffnet, erhält er einen eigenen Eintrag in der Beschreibungstabelle der geöffneten Datei mit seiner Position in der Datei, was genau das ist, was benötigt wird. Der Zweck der offenen Dateibeschreibungstabelle besteht also darin, übergeordneten und untergeordneten Prozessen die gemeinsame Nutzung eines einzelnen Zeigers auf eine Datei zu ermöglichen, aber private Zeiger anderen Prozessen zuzuweisen.

Also (zurück zum Problem der Leseausführung): Wir haben gezeigt, wie die Dateiposition und der I-Node bestimmt werden. Der I-Knoten enthält die Festplattenadressen der ersten 12 Blöcke der Datei. Wenn eine Position in einer Datei innerhalb der ersten 12 Blöcke liegt, wird der gewünschte Block der Datei gelesen und die Daten an den Benutzer kopiert. Bei Dateien, die länger als 12 Blöcke sind, enthält der I-Node die Festplattenadresse eines einzelnen indirekten Blocks (Abbildung 10.19). Dieser Block enthält die Plattenadressen weiterer Plattenblöcke. Wenn die Blockgröße beispielsweise 1 KB beträgt und die Festplattenadresse 4 Bytes belegt, kann ein einzelner indirekter Block bis zu 256 Festplattenadressen speichern. Mit diesem Schema können Sie Dateien mit einer Größe von bis zu 268 KB unterstützen.

Dateisystem(englisches Dateisystem) – eine Ordnung, die die Art und Weise der Organisation, Speicherung und Benennung von Daten auf Informationsspeichermedien von IT-Geräten festlegt (unter Verwendung tragbarer Flash-Speicherkarten zur wiederholten Aufzeichnung und Speicherung von Informationen in tragbaren Geräten). elektronische Geräte: Digitalkameras, Mobiltelefone usw.) und Computerausrüstung. Es definiert das Format des Inhalts und der physischen Speicherung von Informationen, die normalerweise in Form von Dateien gruppiert sind. Ein bestimmtes Dateisystem bestimmt die Größe des Dateinamens (Ordners), die maximal mögliche Datei- und Partitionsgröße sowie eine Reihe von Dateiattributen. Einige Dateisysteme bieten Dienstfunktionen wie Zugriffskontrolle oder Dateiverschlüsselung.

Dateisystemaufgaben

Die Hauptfunktionen eines jeden Dateisystems zielen auf die Lösung folgender Aufgaben ab:

Dateibenennung;

Softwareschnittstelle zum Arbeiten mit Dateien für Anwendungen;

Abbildung des logischen Modells des Dateisystems auf die physische Organisation der Datenspeicherung;
Organisation der Widerstandsfähigkeit des Dateisystems gegenüber Stromausfällen, Hardware- und Softwarefehlern;

In Mehrbenutzersystemen stellt sich eine weitere Aufgabe: die Dateien eines Benutzers vor unbefugtem Zugriff eines anderen Benutzers zu schützen und sicherzustellen Zusammenarbeit Bei Dateien beispielsweise: Wenn eine Datei von einem Benutzer geöffnet wird, steht die gleiche Datei für andere Benutzer vorübergehend im schreibgeschützten Modus zur Verfügung.

Ein Dateisystem ist die Grundstruktur, die ein Computer zum Organisieren von Informationen auf seiner Festplatte verwendet. Bei der Installation eines neuen Festplatte Es muss für ein bestimmtes Dateisystem partitioniert und formatiert werden, woraufhin Daten und Programme darauf gespeichert werden können. Unter Windows gibt es drei Möglichkeiten Dateisysteme: NTFS, FAT32 und das selten verwendete Legacy-FAT-System (auch bekannt als FAT16).

NTFS ist das bevorzugte Dateisystem für diese Windows-Version. Es hat viele Vorteile gegenüber dem älteren FAT32-System; Einige davon sind unten aufgeführt.

Die Möglichkeit zur automatischen Wiederherstellung nach einigen Festplattenfehlern (FAT32 verfügt nicht über diese Funktion).
Verbesserte Unterstützung für große Festplatten.
Mehr hochgradig Sicherheit. Mithilfe von Berechtigungen und Verschlüsselung können Sie Benutzern den Zugriff auf bestimmte Dateien verweigern.

Bisher wurden das FAT32-Dateisystem und das selten verwendete FAT-System verwendet Windows-Versionen, einschließlich Windows 95, Windows 98 und Windows Millenium Edition. Das FAT32-Dateisystem bietet nicht die Sicherheitsstufe von NTFS. Wenn Ihr Computer also über eine Partition oder ein Volume verfügt, die als FAT32 formatiert ist, sind die Dateien auf dieser Partition für jeden sichtbar, der Zugriff auf den Computer hat. Auch das FAT32-Dateisystem unterliegt Dateigrößenbeschränkungen. In dieser Windows-Version ist es nicht möglich, eine FAT32-Partition mit mehr als 32 GB zu erstellen. Darüber hinaus darf eine FAT32-Partition keine Datei enthalten, die größer als 4 GB ist.

Der Hauptgrund für die Verwendung eines FAT32-Systems besteht darin, dass auf dem Computer entweder Windows 95, Windows 98 oder Windows Millennium Edition oder diese Windows-Version (Konfiguration mit mehreren Betriebssystemen) ausgeführt werden kann. Um eine solche Konfiguration zu erstellen, müssen Sie die vorherige Version des Betriebssystems auf einer als FAT32 oder FAT formatierten Partition installieren und diese zur primären Partition machen (die primäre Partition kann das Betriebssystem enthalten). Andere Partitionen, auf die von früheren Windows-Versionen aus zugegriffen wird, müssen ebenfalls als FAT32 formatiert sein. Mehr frühe Versionen Windows kann nur auf Netzwerk-NTFS-Partitionen oder -Volumes zugreifen. Auf NTFS-Partitionen auf dem lokalen Computer kann nicht zugegriffen werden.

FAT – Vorteile:

Es erfordert etwas RAM, um effektiv zu arbeiten.
Schnelles Arbeiten mit kleinen und mittelgroßen Katalogen.
Die Festplatte macht im Durchschnitt weniger Kopfbewegungen (im Vergleich zu NTFS).
Arbeiten Sie effizient auf langsamen Festplatten.

FAT – Nachteile:

Katastrophaler Leistungsverlust mit zunehmender Fragmentierung, insbesondere bei großen Festplatten (nur FAT32).
Schwierigkeiten beim Direktzugriff auf große Dateien (z. B. 10 % oder mehr der Festplattengröße).
Sehr langsames Arbeiten mit Verzeichnissen, die eine große Anzahl von Dateien enthalten.

NTFS - Vorteile:

Die Dateifragmentierung hat praktisch keine Auswirkungen auf das Dateisystem selbst – die Leistung eines fragmentierten Systems wird nur im Hinblick auf den Zugriff auf die Dateidaten selbst beeinträchtigt.
Auch die Komplexität der Verzeichnisstruktur und die Anzahl der Dateien in einem Verzeichnis stellen keine besonderen Leistungshindernisse dar.
Schneller Zugriff auf ein beliebiges Fragment einer Datei (z. B. Bearbeiten großer WAV-Dateien).
Sehr schneller Zugriff auf kleine Dateien (einige hundert Bytes) – die gesamte Datei befindet sich am selben Ort wie die Systemdaten (MFT-Datensatz).

NTFS – Nachteile:

Erheblicher Systemspeicherbedarf (64 MB sind das absolute Minimum, mehr ist besser).
Langsame Festplatten und Controller ohne Bus-Mastering verringern die Leistung von NTFS erheblich.
Die Arbeit mit mittelgroßen Verzeichnissen ist schwierig, da diese fast immer fragmentiert sind.
Eine Festplatte, die über einen längeren Zeitraum mit 80–90 % Auslastung betrieben wird, weist eine extrem niedrige Leistung auf.

Die folgenden Dateisysteme gelten als „nativ“ für Linux (also diejenigen, auf denen es installiert und von denen aus es gestartet werden kann): ext2fs, ext3fs, ext4fs, ReiserFS, XFS, JFS. Sie werden normalerweise bei der Installation der allermeisten Distributionen als Auswahl angeboten. Natürlich gibt es Möglichkeiten Linux-Installationen zu FAT/VFAT/FAT32-Dateisystemen, aber das ist nur für die Damen und Herren, die sich mit Perversionen auskennen, und ich werde nicht darüber sprechen.

Die Hauptkriterien bei der Auswahl eines Dateisystems sind in der Regel Zuverlässigkeit und Leistung. In manchen Fällen müssen Sie auch den Kompatibilitätsfaktor berücksichtigen – in diesem Fall ist damit die Fähigkeit anderer Betriebssysteme gemeint, auf ein bestimmtes Dateisystem zuzugreifen.
Ich beginne die Rezension mit ReiserFS – denn der Grund für das Verfassen dieser Notiz war die Frage: Was sind kleine Dateien? Schließlich ist bekannt, dass die Effizienz beim Arbeiten mit kleinen Dateien die Stärke dieses Dateisystems ist.

Mit kleinen Dateien sind also Dateien gemeint, die kleiner sind als ein logischer Block des Dateisystems, der in Linux in den meisten Fällen vier Kilobyte entspricht, obwohl er bei der Formatierung innerhalb bestimmter Grenzen (abhängig vom jeweiligen FS) angegeben werden kann. In jedem Unix-ähnlichen Betriebssystem gibt es unzählige solcher kleinen Dateien. Ein typisches Beispiel sind die Dateien, die den Baum der FreeBSD-Ports, Gentoo-Portagen und ähnlicher portähnlicher Systeme bilden.
In den meisten Dateisystemen verfügen solche Minidateien sowohl über einen eigenen Inode (einen Informationsknoten, der Metainformationen über die Datei enthält) als auch über einen Datenblock, was sowohl zu einem Speicherplatzverbrauch als auch zu einer Leistungseinbuße bei Dateivorgängen führt. Dies ist insbesondere der Grund für die katastrophale Rücksichtnahme des FreeBSD-Dateisystems (sowohl des alten UFS als auch des neuen UFS2) bei der Arbeit mit seinem eigenen Portsystem.

Im ReiserFS-Dateisystem werden in solchen Fällen keine separaten Blöcke für Daten zugewiesen – es schafft es, die Dateidaten direkt in den Inode-Bereich zu verschieben. Dadurch wird Speicherplatz gespart und die Leistung gesteigert – buchstäblich um ein Vielfaches im Vergleich zu allen anderen FS.
Dieser Umgang mit kleinen ReiserFS-Dateien hat zu der Legende über deren Unzuverlässigkeit geführt. Tatsächlich verschwinden beim Zusammenbruch des Dateisystems (also der Zerstörung von Servicebereichen) auch die Daten, die sich zusammen mit seinen Inodes befinden, mit ihnen – und zwar unwiderruflich. Während in Dateisystemen, in denen Inodes und Datenblöcke immer räumlich getrennt sind, letztere theoretisch wiederhergestellt werden können. Für ext2/ext3 gibt es also sogar Tools, mit denen Sie dies tun können.

Allerdings erweckt diese, wie jede Legende, nur den Eindruck von Authentizität. Erstens betrifft ein dauerhafter Datenverlust nur sehr kleine Dateien. Unter den Benutzerversionen gibt es praktisch keine solchen, und alle anderen können problemlos aus dem Distributionskit wiederhergestellt werden.
Zweitens war es kein Zufall, dass ich das Wort „theoretisch“ verwendet habe, als ich über die Möglichkeit sprach, Daten aus Blöcken wiederherzustellen, die ihre Verbindung zu ihren Inodes verloren haben. Denn in der Praxis ist diese Tätigkeit äußerst arbeitsintensiv und liefert kein garantiertes Ergebnis. Jeder, der dies schon einmal tun musste, wird zustimmen, dass man sich dem nur aus völliger Verzweiflung hingeben kann. Und das gilt für alle Linux-Dateisysteme. Daher kann dieser Aspekt bei der Auswahl eines Dateisystems vernachlässigt werden.

In Bezug auf die Gesamtleistung ist ReiserFS definitiv schneller als alle anderen Journal-FS und in mancher Hinsicht ext2 überlegen. Einen Geschwindigkeitsvergleich einiger gängiger Dateivorgänge finden Sie hier.
Bei ReiserFS ist die Kompatibilitätssituation jedoch etwas schlechter. Der Zugriff darauf ist von Windows-Betriebssystemen aus meines Wissens nach nicht möglich. Einige Betriebssysteme der BSD-Familie (DragonFlyBSD, FreeBSD) unterstützen dieses Dateisystem, allerdings im schreibgeschützten Modus. Selbst die Wahrscheinlichkeit, dass eine beliebige Linux-LiveCD aus früheren Jahren keine ReiserFS-Unterstützung hat, ist nicht Null.

Und hier ist es an der Zeit, sich an ext3fs zu erinnern. Sein Vorteil liegt keineswegs in einer höheren Zuverlässigkeit – dies ist die gleiche Legende wie die Instabilität von ReiserFS. Ich habe von ext3fs-Abstürzen nicht weniger gehört als von ähnlichen Vorfällen mit ReiserFS. Ich selbst konnte weder das eine noch das andere zerstören. Außer, dass es mit ext2 funktionierte – aber selbst dann schon vor sehr langer Zeit, zur Zeit von Kernel 2.2 (oder sogar 2.0).

Nein, der Hauptvorteil von ext3fs ist seine Kompatibilität – es wird garantiert von jedem Linux-System gelesen. Zum Beispiel, als ich eine alte Live-CD wiederherstellte – eine Situation, die praktisch nicht so unglaublich ist, musste ich mich darauf einlassen. Auch hier können die meisten BSD-Systeme ext3fs problemlos verstehen (allerdings ohne Protokollierung). Für Windows gibt es meines Wissens auch alle möglichen Treiber und Plug-Ins für gängige Dateimanager(Typ Totaler Kommandant), der den Zugriff auf Partitionen mit ext2fs/ext3fs ermöglicht.

Leistungstechnisch hinterlässt ext3fs einen gemischten Eindruck. Erstens hängt seine Leistung stark vom Protokollierungsmodus ab, von dem es drei gibt: mit vollständiger Datenprotokollierung, teilweiser Protokollierung und Protokollierung nur von Metadaten. In jedem Modus wird eine unterschiedliche Leistung angezeigt verschiedene Typen Dateioperationen. Allerdings ist die Leistung in keinem Fall rekordverdächtig.

Wenn jedoch der Leistungsanspruch an erster Stelle steht, dann ist ext2fs konkurrenzlos – allerdings muss man sich in diesem Fall überhaupt mit der fehlenden Protokollierung zufrieden geben. Und damit einhergehend mit langwierigen Überprüfungen des Dateisystems im Falle eines fehlerhaften Herunterfahrens – und das kann bei der Größe moderner Festplatten sehr lange dauern …

Folgendes kann über XFS gesagt werden. In puncto Kompatibilität gilt für ReiserFS alles, was für ReiserFS geschrieben wurde – zudem wurde es bis vor einiger Zeit nicht vom Standard-Linux-Kernel unterstützt. Auch leistungstechnisch kann XFS nicht glänzen und liegt insgesamt in etwa auf dem gleichen Niveau wie ext3fs. Und der Vorgang des Löschens von Dateien ist im Allgemeinen deprimierend langsam.
Nach meinen Beobachtungen lohnt sich der Einsatz von XFS dann, wenn man nicht nur mit großen, sondern mit sehr großen Dateien arbeitet – bei denen es sich eigentlich nur um DVD-Bilder und Videodateien handelt.

Lassen Sie mich auf die Frage der Zuverlässigkeit zurückkommen. Eine banale Stromabschaltung während der normalen Arbeit des Benutzers wird in der Regel von allen Journaled-File-Systemen problemlos toleriert (und keines von ihnen gewährleistet die Sicherheit von Benutzeroperationen, die nicht auf die Festplatte geschrieben werden – die Rettung ertrinkender Menschen bleibt die Arbeit der ertrinkenden Menschen selbst). Zwar ist es für jedes Dateisystem möglich, eine Situation zu simulieren, in der das Ausschalten des Stroms zu mehr oder weniger schwerwiegenden Schäden führt. Allerdings in wahres Leben Es ist unwahrscheinlich, dass solche Situationen auftreten. Und Sie können sie durch den Kauf einer Quelle vollständig beseitigen unterbrechungsfreie Stromversorgung- Es gibt mehr Vertrauen in die Sicherheit der Daten als die Art des Dateisystems. Nun ja, die einzige Garantie für die Wiederherstellung beschädigter Daten können in jedem Fall regelmäßige Backups sein...

Ich denke, dass die oben dargestellten Informationen für eine fundierte Entscheidung ausreichen. Meine persönliche Wahl war in den letzten Jahren ReiserFS. Gelegentlich ist es auf Systemen, auf denen es gerechtfertigt ist, alles Mögliche außerhalb der Root-Partition zu verschieben, sinnvoll, ext3fs für das Root-Dateisystem und ReiserFS für alle anderen zu verwenden.

Wenn eine eigene Partition für das /boot-Verzeichnis bereitgestellt wird (und dies wird von seinen Entwicklern bei Verwendung des GRUB-Bootloaders empfohlen), ist kein anderes Dateisystem als ext2fs dafür gerechtfertigt und eine Protokollierung hier macht keinen Sinn. Wenn Sie schließlich eine separate Partition für alle Arten von Multimedia-Materialien erstellen, können Sie über XFS nachdenken.

Wenn wir die Erklärung methodischer angehen

ext – in den frühen Tagen von Linux war ext2 (erweitertes Dateisystem Version 2) vorherrschend. Seit 2002 wurde es durch das ext3-System ersetzt, das weitgehend kompatibel zu ext2 ist, aber auch Protokollierungsfunktionen und ab Kernel-Version 2.6 auch ACLs unterstützt. Die maximale Dateigröße beträgt 2 TB, die maximale Dateisystemgröße beträgt 8 TB. Ende 2008 wurde offiziell die Veröffentlichung von ext4 angekündigt, das abwärtskompatibel zu ext3 ist, jedoch viele Funktionen effizienter als zuvor implementiert. Darüber hinaus beträgt die maximale Dateisystemgröße 1 EB (1.048.576 TB), und Sie können davon ausgehen, dass dies für einige Zeit ausreicht. Über reiser – das System wurde nach seinem Gründer Hans Reiser benannt und war das erste System mit Protokollierungsfunktionen, das für Daten auf den Linux-Kernel zugreift. Die SUSE-Version von Zp galt zeitweise sogar als Standard. Die Hauptvorteile von reiser im Vergleich zu ext3 sind eine höhere Geschwindigkeit und Platzierungseffizienz beim Arbeiten mit kleinen Dateien (und in einem Dateisystem sind die meisten Dateien in der Regel klein). Mit der Zeit kam die Entwicklung der Reisefer jedoch zum Stillstand. Die Veröffentlichung der Version 4 ist schon lange angekündigt, die noch nicht fertig ist, und der Support für Version 3 wurde eingestellt. Über xfs – das xfs-Dateisystem wurde ursprünglich für SGI-Workstations entwickelt, die unter dem Betriebssystem IRIX laufen. Xfs eignet sich besonders gut für die Arbeit mit großen Dateien und ist besonders ideal für die Arbeit mit Streaming-Videos. Das System unterstützt Kontingente und erweiterte Attribute (ACLs).
jfs

jfs - a66peBHaTypaJFS steht für „Journaled File System“. Es wurde ursprünglich für IBM entwickelt und dann für Linux angepasst. JFS genoss unter Linux nie große Anerkennung und fristet derzeit ein erbärmliches Dasein, da es anderen Dateisystemen unterlegen ist.
brtfs

brtfs – Wenn es der Wille der führenden Kernel-Entwickler ist, hat das brtfs-Dateisystem in Linux eine glänzende Zukunft. Dieses System wurde von Grund auf bei Oracle entwickelt. Es umfasst Unterstützung für Device-Mapper und RAID. Brtfs ist dem von Sun entwickelten ZFS-System am ähnlichsten. Zu ihrem Allerbesten interessante Funktionen umfasst On-the-Fly-Dateisystemprüfungen sowie SSD-Unterstützung (Solid-State-Laufwerke sind vorhanden). Festplatten, Betrieb auf Basis von Flash-Speicher). Leider werden die Arbeiten an BRTFS in absehbarer Zeit nicht abgeschlossen sein. Fedora bietet ab Version 11 die Möglichkeit, brtfs zu installieren, ich empfehle die Verwendung jedoch nur Dateisystementwicklern!
Es gibt kein „schnellstes“ oder „bestes“ Dateisystem – die Beurteilung hängt davon ab, wofür Sie das System verwenden möchten. Für Linux-Anfänger, die damit arbeiten lokalen Computer Es wird empfohlen, mit ext3 und für Serveradministratoren mit ext4 zu arbeiten. Natürlich ist die Betriebsgeschwindigkeit bei ext4 höher als bei ext3, aber gleichzeitig ist die Situation mit der Datenzuverlässigkeit im ext4-System viel schlechter – Sie können durchaus Informationen verlieren, wenn das System plötzlich abschaltet.

Wenn Sie ein zweites UNIX-ähnliches Betriebssystem auf Ihrem Computer installiert haben, dann werden Ihnen die folgenden Dateisysteme beim Datenaustausch (von einem Betriebssystem zum anderen) nützlich sein.

sysv – wird in SCO, Xenix und Coherent OS verwendet.

ufs – wird in FreeBSD, NetBSD, NextStep und SunOS verwendet. Linux kann Informationen aus solchen Dateisystemen nur lesen, aber keine Änderungen an den Daten vornehmen. Um von BSD aus auf Segmente zugreifen zu können, benötigen Sie zusätzlich die BSD-Disklabel-Erweiterung. Eine ähnliche Erweiterung gibt es für SunOS-Partitionstabellen.

ZFS ist relativ neues System, entwickelt von Sun für Solaris. Da ZFS-Code nicht GPL-kompatibel ist, kann er nicht in den Linux-Kernel integriert werden. Aus diesem Grund unterstützt Linux dieses Dateisystem nur indirekt über FUSE.
Windows, Mac OS X

Die folgenden Dateisysteme sind beim Informationsaustausch mit MS DOS, Windows, OS/2 und Macintosh nützlich.

vfat – wird in Windows 9x/ME verwendet. Linux kann Informationen aus solchen Partitionen lesen und Änderungen daran vornehmen. Mit den vfat-Systemtreibern können Sie mit älteren MS-DOS-Dateisystemen (8 + 3 Zeichen) arbeiten.

ntfs – das System wird in allen modernen Windows-Versionen verwendet: otNT und höher. Linux kann seine Dateien lesen und ändern.

hfs und hfsplus – diese Dateisysteme werden in Apple-Computern verwendet. Linux kann seine Dateien lesen und ändern.

Daten-CDs und -DVDs verwenden normalerweise ihre eigenen Dateisysteme.

iso9660 – Das Dateisystem für CD-ROMs ist im ISO-9660-Standard beschrieben, der nur kurze Dateinamen zulässt. Lange Namen werden auf verschiedenen Betriebssystemen unterschiedlich unterstützt und verwenden eine Vielzahl von Erweiterungen, die untereinander inkompatibel sind. Linux kann sowohl die unter UNIX übliche Rockridge-Erweiterung als auch die von Microsoft entwickelte Joliet-Erweiterung ausführen.

udf – dieses Format (Universal Disk Format) erschien und entwickelte sich als Nachfolger von ISO 9660.

Netzwerkdateisysteme

Dateisysteme müssen sich nicht auf befinden lokale Festplatte- Sie
kann eine Verbindung zu einem Computer und über ein Netzwerk herstellen. Der Linux-Kernel unterstützt verschiedene Netzwerkdateisysteme, von denen die folgenden am häufigsten verwendet werden.

smbfs/cifs – Hilfe beim Herstellen einer Verbindung Netzwerkverzeichnisse Windows oder Samba in den Verzeichnisbaum.

NFS ist das wichtigste Netzwerkdateisystem unter UNIX.

Coda – dieses System ist NFS sehr ähnlich. Es verfügt über viele zusätzliche Funktionen, ist jedoch nicht sehr verbreitet.

ncpfs – läuft auf dem NetWare-Kernel-Protokoll; oH wird von Novell Netware verwendet.

Virtuelle Dateisysteme

Linux verfügt über mehrere Dateisysteme, die nicht darauf ausgelegt sind, Daten auf der Festplatte (oder anderen Speichermedien) zu speichern, sondern nur darauf, Informationen zwischen Kernel und Benutzerprogrammen auszutauschen.
devpts – Dieses Dateisystem ermöglicht den Zugriff auf Pseudoterminals (abgekürzt als PTY) über /dev/pts/* gemäß der UNIX-98-Spezifikation. (Pseudoterminals emulieren eine serielle Schnittstelle. Auf UNIX/Linux-Systemen werden solche Schnittstellen von Terminalemulatoren wie xterm verwendet. Typischerweise werden Geräte wie /dev/ttypn verwendet. Im Gegensatz dazu definiert die UNIX-98-Spezifikation neue Geräte. Weitere Detailinformationen werden im Textterminal H0WT0 gemeldet.)
proc und sysfs – das proc-Dateisystem wird verwendet, um Dienstinformationen im Zusammenhang mit der Kernel- und Prozessverwaltung anzuzeigen. Darüber hinaus baut das sysfs-Dateisystem Beziehungen zwischen dem Kernel und der Hardware auf. Beide Dateisysteme werden unter /proc und /sys gemountet.
tmpfs – Dieses System basiert auf Shared Memory nach System V. Es wird normalerweise an der Position /dev/shm gemountet und ermöglicht einen effizienten Informationsaustausch zwischen zwei Programmen. Bei einigen Distributionen (z. B. Ubuntu) werden die Verzeichnisse /var/run und /var/lock auch mit dem tmpfs-Dateisystem erstellt. Die Dateien in diesen Verzeichnissen werden von einigen Netzwerk-Daemons zum Speichern von Prozessidentifikationsnummern sowie Dateizugriffsinformationen verwendet. Dank tmpfs werden diese Daten nun im RAM angezeigt. Die Methode garantiert eine hohe Geschwindigkeit und auch, dass nach dem Ausschalten des Computers keine Dateien mehr in den Verzeichnissen /var/run oder /var/lock verbleiben.

usbfs – das usbfs-Dateisystem, beginnend mit Kernel-Version 2.6 und höher, liefert Informationen über angeschlossene USB-Geräte. Es ist normalerweise in das proc-Dateisystem integriert. Informationen zur USB-Geräteunterstützung unter Linux.

Andere Dateisysteme

auto – tatsächlich gibt es kein Dateisystem unter diesem Namen. Das Wort auto kann jedoch in /etc/fstab oder mit dem Mount-Befehl verwendet werden, um das Dateisystem anzugeben. In diesem Fall wird Linux versuchen, das Dateisystem selbstständig zu erkennen. Diese Methode funktioniert mit den meisten gängigen Dateisystemen.
autofs, autofs4

autofs, autofs4 sind ebenfalls keine Dateisysteme, sondern Kernel-Erweiterungen, die den Mount-Befehl für ausgewählte Dateisysteme automatisch ausführen. Wenn ein Dateisystem längere Zeit nicht verwendet wird, wird der Befehl umount automatisch darauf ausgeführt. Diese Methode bietet sich vor allem dann an, wenn von vielen NFS-Verzeichnissen nur wenige gleichzeitig aktiv genutzt werden.

Um solche Vorgänge auszuführen, führt das Skript /etc/init.d/autofs beim Systemstart automatisch das Automount-Programm aus. Die Konfiguration erfolgt über die Datei /etc/auto.master. Die entsprechenden Programme werden beispielsweise bei Red Hat und Fedora automatisch installiert. In jedem Fall wird autofs erst nach der Konfiguration von /etc/auto.master oder /etc/auto.misc aktiviert.
Cramfs und Squashfs

cramfs und squashfs – Cram- und Squash-Dateisysteme sind schreibgeschützt. Sie dienen dazu, möglichst viele gezippte Dateien in den Flash-Speicher oder ROM (Nur-Lese-Speicher) zu „packen“.

Sicherung – FUSE steht für Filesystem in Userspace und ermöglicht die Entwicklung und Verwendung von Dateisystemtreibern außerhalb des Kernels. Daher wird FUSE immer mit einem externen Dateisystemtreiber verwendet. FUSE funktioniert insbesondere mit dem NTFS-Treiber ntfs-3g.

gfs und ocfs – Global File System und Cluster File System von Oracle (Oracle Cluster File System) ermöglichen den Aufbau riesiger Netzwerkdateisysteme, auf die viele Computer gleichzeitig parallel zugreifen können.

jffs und yaffs – Journaling-Dateisystem für Flash-Medien (Journaling Flash-Datei System) und Yet Another Flash File System sind speziell für die Verwendung optimiert Solid State Drives und Flash-Medien. Mithilfe spezieller Algorithmen versuchen sie, alle Speicherzellen gleichmäßig zu nutzen (Wear-Leveling-Technologie), um einen vorzeitigen Systemausfall zu vermeiden.
Schleife

Schleife – wird für die Arbeit mit Pseudogeräten verwendet. Ein Loopback-Gerät ist ein Adapter, der als Blockgerät auf eine reguläre Datei zugreifen kann. Dank dessen können Sie jedes Dateisystem in jeder Datei platzieren und es dann mit mount mit dem Verzeichnisbaum verbinden. Die dafür verantwortliche Kernelfunktion – Pseudo-Device-Support – ist im Loop-Modul implementiert.

Es gibt eine Vielzahl von Verwendungsmöglichkeiten für Pseudogeräte. Sie können insbesondere beim Erstellen von Initial RAM Disks für GRUB oder LILO, bei der Implementierung verschlüsselter Dateisysteme oder beim Testen von ISO-Images für CDs verwendet werden.

Dateisysteme für Speichermedien

Dateisysteme
ISO 9660
Joliet ISO 9660-Dateisystemerweiterung.
Rock Ridge (RRIP, IEEE P1282) ist eine ISO 9660-Dateisystemerweiterung, die zum Speichern von Dateiattributen entwickelt wurde, die in Betriebssystemen verwendet werden. POSIX-Systeme
Amiga Rock Ridge-Erweiterungen
El Torito
Apple ISO9660-Erweiterungen
HFS, HFS+
Universal Disk Format ist eine Spezifikation eines vom Betriebssystem unabhängigen Dateisystemformats zum Speichern von Dateien auf optischen Medien. UDF ist eine Implementierung des ISO/IEC 13346-Standards
Mount Rainier

14 Jun

Dateisysteme ext2, ext3, XFS, ReiserFS, NTFS

Dateisystem- Dies ist die Reihenfolge, die die Art und Weise der Organisation, Speicherung und Benennung von Daten auf elektronischen Speichermedien in Computern bestimmt.

Die Vielfalt der Dateisysteme erklärt sich aus der Tatsache, dass jedes für seine eigenen spezifischen Aufgaben erfunden wurde. Manche schreiben sehr schnell kleine Dateien (z. B. bis zu 1 GB), interagieren aber gleichzeitig schlecht mit großen Dateien oder arbeiten überhaupt nicht mit ihnen. Einige sind aus Sicherheitsgründen gut, andere aus Sicht der Lese-/Schreibgeschwindigkeit. Jedes Dateisystem hat seine eigenen Vor- und Nachteile, Schwachstellen und besonderen Fähigkeiten.

IN Linux Die am häufigsten verwendeten Dateisystemtypen sind:

1. ext2- steht für Zweites erweitertes Dateisystem(zweites erweitertes Dateisystem). 1993 von Remy Card als Dateisystem für den Linux-Kernel entwickelt, war es von 1993 bis 2001 das Hauptdateisystem Linux.
   Der Vorteil ist eine hohe Lese-/Schreibgeschwindigkeit.
   Der Hauptnachteil des Systems ext2 ist, dass es nicht protokolliert wird, aber gerade deshalb eine großartige Leistung aufweist ( Protokollierung ist ein Journaling-Prozess, der eine Liste von Änderungen speichert, die dazu beitragen, die Integrität des Dateisystems bei verschiedenen Systemausfällen aufrechtzuerhalten.
2. ext3- steht für Drittes erweitertes Dateisystem(dritte Version des erweiterten Dateisystems). 2001 von Stephen Tweedy entwickelt, wird noch heute in Distributionen verwendet Linux. Wurde als verbesserte geboren ext2.
   Der Vorteil dieses Systems besteht darin, dass es protokolliert wird, das heißt, seine Zuverlässigkeit erhöht sich im Vergleich zu deutlich ext2.
   Der Nachteil ist eine etwas geringere Leistung und Lese-/Schreibgeschwindigkeit.
3. XFS— Vom Unternehmen entwickelt Siliziumgrafiken im Jahr 1993 wurde der Kern hinzugefügt Linux als Dateisystem im Jahr 2002 für die gesamte Distributionsfamilie eingeführt Linux, wird derzeit als „native“ in der Distribution verwendet roter Hut.
   Der Vorteil ist das Vorhandensein einer Metadatenprotokollierung, hohe Stabilität, Unterstützung für die Verteilung von Eingabe-/Ausgabeströmen in Gruppen, hohe Geschwindigkeit Lesen/Schreiben, eine Defragmentierung ist auch bei gemounteter Partition möglich und Sie können die Größe des Dateisystems erhöhen. Funktioniert am effektivsten mit großen Dateien.
   Der Nachteil besteht darin, dass die Partitionsgröße nicht reduziert werden kann, die Metadatenverarbeitung nicht so schnell ist und bei kleinen Dateien deutlich langsamer arbeitet als bei anderen Dateisystemtypen.
4. ReiserFS- vom Unternehmen entwickelt Namesys unter der Leitung von Hans Reiser im Jahr 2001. Wird nur auf Betriebssystemen verwendet Linux. Es war das erste Journaled-File-System, das in den Kernel übernommen wurde.
   Der Vorteil dieses Dateisystems besteht darin, dass es mit kleinen Dateien sehr schnell arbeitet (die Lese-/Schreibgeschwindigkeit ist höher als die des ext4), unterstützt die Protokollierung.
   Der Nachteil ist, dass sich seine Entwicklung durch die Verhaftung seines Anführers Hans Reiser merklich verlangsamt hat und es keine Hintergrundverschlüsselung gibt.
5. NTFS- steht für Dateisystem mit neuer Technologie(Dateisystem neue Technologie). Im Juli 1993 vom Unternehmen entwickelt Microsoft. Weit verbreitet in verschiedenen Betriebssystemen sowie in verschiedenen Speichermedien.
   Der Vorteil liegt in der integrierten Möglichkeit, den Zugriff auf Daten für verschiedene Benutzer zu beschränken sowie Beschränkungen für den maximalen Speicherplatz, die Verwendung eines Journaling-Systems und das schnelle Lesen/Schreiben kleiner Dateien festzulegen.
   Der Nachteil ist, dass man für einen stabilen Betrieb ein kleines benötigt Rom Ein PC mit großen Dateien ist langsam, die Länge des Pfades zu den Dateien ist begrenzt (32.767 Unicode-Zeichen).

Auf diese einfache Weise haben wir „Dateisysteme“ herausgefunden ext2, ext3, XFS, ReiserFS, NTFS«!

WLADIMIR MESCHKOW

ext2-Dateisystemarchitektur

Der Artikel diskutiert die logische Struktur von ext2, dem Dateisystem des Linux-Betriebssystems.

Hauptkomponenten des ext2-Dateisystems

Wie jedes UNIX-Dateisystem umfasst das ext2-Dateisystem die folgenden Komponenten:

• Blöcke und Blockgruppen;
• Informationsknoten;
• Superblock.

Blöcke und Blockgruppen

Der gesamte Speicherplatz der Festplattenpartition ist in Blöcke fester Größe unterteilt, die ein Vielfaches der Sektorgröße sind – 1024, 2048 und 4096 Byte. Die Blockgröße wird beim Erstellen eines Dateisystems auf einer Festplattenpartition angegeben. Eine kleinere Blockgröße spart Festplattenspeicher, begrenzt aber auch die maximale Dateisystemgröße. Alle Blöcke haben Seriennummern. Um die Fragmentierung und die Anzahl der Bewegungen der Festplattenköpfe beim Lesen großer Datenmengen zu reduzieren, werden Blöcke zu Gruppen zusammengefasst.

Informationsdrehscheibe

Das Grundkonzept eines Dateisystems ist der Informationsknoten oder Inode. Dabei handelt es sich um eine spezielle Struktur, die Informationen über die Attribute und den physischen Speicherort der Datei enthält. Die Attribute einer Datei sind ihr Typ (normale Datei, Verzeichnis usw.), Zugriffsrechte darauf, Besitzer-ID, Größe, Erstellungszeit. Informationen zum physischen Standort sind eine Folge absoluter Blocknummern, die Dateidaten enthalten.

Superblock

Superblock ist das Hauptelement des ext2-Dateisystems. Es enthält die folgenden Dateisysteminformationen (die Liste ist unvollständig):

• die Gesamtzahl der Blöcke und Inodes im Dateisystem;
• Anzahl freier Blöcke und Inodes im Dateisystem;
• Blockgröße des Dateisystems;
• Anzahl der Blöcke und Inodes in der Gruppe;
• Inode-Größe;
• Dateisystem-ID;
• Nummer des ersten Datenblocks.

Mit anderen Worten: Dies ist die Nummer des Blocks, der den Superblock enthält. Diese Zahl ist immer 0, wenn die Blockgröße des Dateisystems größer als 1024 Byte ist, und 1, wenn die Blockgröße 1024 Byte beträgt.

Die Integrität des Superblocks wirkt sich direkt auf die Leistung des Dateisystems aus. Das Betriebssystem erstellt mehrere Sicherungskopien des Superblocks, damit dieser im Schadensfall wiederhergestellt werden kann. Die Masterkopie befindet sich in einem Abstand von 1024 Bytes vom Anfang der Partition, auf der das Dateisystem erstellt wurde (die ersten 1024 Bytes sind für den Betriebssystem-Loader reserviert).

Frühere Versionen des ext2-Dateisystems erstellten Kopien des Superblocks am Anfang jeder Blockgruppe. Dies führte zu einem großen Verlust an Speicherplatz, sodass später die Anzahl der Superblock-Backups reduziert und die Blockgruppen 0, 1, 3, 5 und 7 zugewiesen wurden, um sie unterzubringen.

Blockgruppenformat

Verallgemeinert Strukturschema Das ext2-Dateisystem ist in Abb. dargestellt. 1.

Fast alle Blockgruppen haben das gleiche Format. In jeder Gruppe werden neben Informationsblöcken auch Informationen über die Belegung der Blöcke und den Inode der Gruppe in Form einer Bitmap gespeichert. Blockgruppe 0 enthält außerdem einen Superblock und eine Gruppendeskriptortabelle, die wir uns weiter unten ansehen werden.

Die Blockbelegungsbitmap befindet sich normalerweise im ersten Block einer Gruppe. Wenn es in der Gruppe einen Backup-Superblock gibt, befindet sich die Bitmap im zweiten Block der Gruppe. Die Bitmap-Größe beträgt einen Block. Jedes Bit dieser Karte repräsentiert den Zustand des Blocks. Ist das Bit gesetzt (1), ist der Block belegt, ist es zurückgesetzt (0), ist der Block frei. Der erste Block der Gruppe entspricht dem Nullbit der Karte, der zweite Block dem ersten Bit usw.

Inodes, die sich innerhalb derselben Gruppe befinden, werden in einer Tabelle gesammelt. In der Inode-Belegungsbitmap einer Gruppe charakterisiert jedes Bit den Zustand eines Elements in der Inode-Tabelle der Gruppe.

Jede Blockgruppe wird mithilfe eines Blockgruppendeskriptors beschrieben. Ein Gruppendeskriptor ist eine Struktur, die Informationen über die Adressen der Blockbelegungs-Bitmap, der Inode-Belegungs-Bitmap und der Inode-Tabelle der entsprechenden Gruppe enthält. Alle Gruppendeskriptoren werden in einer Gruppendeskriptortabelle gesammelt, die in der Blockgruppe 0 gespeichert wird. Genau wie bei einem Superblock erstellt das Betriebssystem Backups Gruppendeskriptortabellen.

Algorithmus zum Lesen von Dateien

Jeder Inode hat wie ein Block eine Sequenznummer, die innerhalb des Dateisystems eindeutig ist und Informationen zu nur einer Datei enthält. Um Zugriff auf den Inhalt einer Datei zu erhalten, müssen Sie daher die Seriennummer des entsprechenden Inodes kennen.

Wie oben erwähnt, sind Informationen über den physischen Speicherort der Datei im Inode enthalten. Bei diesen Informationen handelt es sich um eine Folge von 32-Bit-Blocknummern, die die Dateidaten enthalten (Abbildung 1). Die ersten 12 Nummern sind direkte Links zu Informationsblöcken (direkte Blocknummer). Die 13. Nummer ist ein indirekter Link (indirekte Blocknummer). Es enthält die Adresse des Blocks, in dem die Adressen der Informationsblöcke gespeichert sind. Die 14. Zahl ist eine doppelte indirekte Verbindung (doppelte Blockzahl), die 15. Zahl ist eine dreifache indirekte Verbindung (dreifache Blockzahl).

Der Dateiname ist nicht im Inode enthalten; die Entsprechung zwischen Dateinamen und Inode-Nummern erfolgt über Verzeichnisse.

Kataloge

Dateien auf UNIX- und POSIX-Systemen werden in einem baumartigen hierarchischen Dateisystem gespeichert. Das Dateisystem-Root ist das Root-Verzeichnis, angegeben durch das Symbol „/“. Jeder Zwischenknoten im Dateisystembaum ist ein Verzeichnis. Die Endpunkte eines Dateisystembaums sind entweder leere Verzeichnisse oder Dateien. Der absolute Pfadname einer Datei besteht aus den Namen aller Verzeichnisse, die zu der angegebenen Datei führen, beginnend mit dem Stammverzeichnis. Der Pfadname /home/test.file bedeutet also, dass sich die Datei test.file im Home-Verzeichnis befindet, welches wiederum im Root-Verzeichnis „/“ liegt.

Ein Verzeichnis wird wie eine Datei mithilfe eines Inodes beschrieben. Der Inhalt eines Verzeichnisses besteht aus einer Reihe von Einträgen, die jeweils Informationen zu einer Datei enthalten, die sich „innerhalb“ des aktuellen Verzeichnisses befindet.

Ein Verzeichniseintrag hat das folgende Format:

• Seriennummer des Datei-Inodes;
• Datensatzlänge in Bytes;
• Dateiname;
• Länge des Dateinamens.

Die Suche nach der Inode-Nummer einer Datei beginnt immer im Stammverzeichnis. Um beispielsweise die Inode-Nummer einer Datei im Stammverzeichnis zu ermitteln, muss das Betriebssystem den Inhalt des Stammverzeichnisses abrufen, darin einen Eintrag mit dem Namen dieser Datei finden und daraus die Inode-Nummer der Datei extrahieren diesen Eintrag.

Die ersten paar Inode-Nummern sind vom Dateisystem reserviert; ihre Liste ist in der Header-Datei enthalten:

* Spezielle Inode-Nummern

#define EXT2_BAD_INO 1 /* Fehlerhafter Block-Inode */

#define EXT2_ROOT_IN 2 /* Root-Inode */

#define EXT2_ACL_IDX_IN 3 /* ACL-Inode */

#define EXT2_ACL_DATA_INO 4 /* ACL-Inode */

#define EXT2_BOOT_LOADER_INO 5 /* Bootloader-Inode */

#define EXT2_UNDEL_DIR_INO 6 /* Verzeichnis-Inode wiederherstellen */

Inode Nummer 2 (Root-Inode) ist für das Schreiben des Root-Verzeichnisses reserviert. Dieser Inode befindet sich in der Blockgruppe 0 und belegt die zweite Position in der Inode-Tabelle dieser Gruppe. Die Nummer des ersten nicht reservierten Inodes wird im Superblock gespeichert.

Nachdem die Inode-Nummer einer Datei ermittelt wurde, berechnet der Kernel die Nummer der Gruppe, in der sich dieser Inode befindet, und seine Position in der Inode-Tabelle der Gruppe. Durch Lesen von dieser Inode-Position erhält das Betriebssystem volle Informationüber die Datei, einschließlich der Adressen der Blöcke, in denen der Inhalt der Datei gespeichert ist.

Die Nummer der Blockgruppe, in der sich der Inode befindet, wird nach folgender Formel berechnet:

Gruppe = (inode_num - 1) / inodes_per_group

Wo:

• Gruppe– die gewünschte Blockgruppennummer;
• inode_num– Seriennummer des Inodes, der die Datei definiert;
• inodes_per_group– die Anzahl der Inodes in der Gruppe (diese Informationen befinden sich im Superblock).

Die Inode-Position in der Gruppen-Inode-Tabelle wird durch die Formel bestimmt:

index = (inode_num - 1) % inodes_per_groupe

Dabei ist Index die Inode-Position in der Tabelle.

Sehen wir uns ein Beispiel für das Abrufen des Inhalts der Datei test.file an, die sich im Stammverzeichnis befindet. Um die Datei /test.file zu lesen, müssen Sie Folgendes tun:

• Suchen Sie einen Eintrag zu dieser Datei im Array der Einträge im Stammverzeichnis.
• Extrahieren Sie die Seriennummer des Inodes der Datei und berechnen Sie die Nummer der Gruppe, in der sich dieser Inode befindet.
• Extrahieren Sie die Adresse der Inode-Tabelle der Gruppe aus dem Deskriptor dieser Gruppe.
• Berechnen Sie die Inode-Position in dieser Tabelle.
• Datei-Inode lesen;
• Extrahieren Sie die Adressen von Informationsblöcken aus dem Inode und lesen Sie die in diesen Blöcken enthaltenen Informationen.

In Abb. Abbildung 2 zeigt im Detail die Schritte zum Lesen der Datei /test.file.

Schritte 1-6 – Auslesen des Stammverzeichnisses:

1. Ab Blockgruppe 0 wird die Gruppendeskriptortabelle gelesen.
2. Der Blockgruppendeskriptor 0 wird aus der Gruppendeskriptortabelle abgerufen und die Adresse der Inode-Tabelle der Gruppe 0 wird daraus gelesen.
3. Die Inode-Tabelle wird aus Blockgruppe 0 gelesen.
4. Die Inode-Nummer des Stammverzeichnisses ist fest und gleich 2, daher wird das zweite Element aus der Inode-Tabelle der Gruppe 0 gelesen, die die Adresse des Blocks mit dem Inhalt des Stammverzeichnisses enthält. Nehmen wir an, dass sich dieser Block in Blockgruppe A befindet.
5. Aus Blockgruppe A wird ein Block gelesen, der Root-Verzeichniseinträge enthält.
6. Es wird nach einem Eintrag namens „test.file“ gesucht. Wird ein solcher Eintrag gefunden, wird daraus die Inode-Nummer der Datei „test.file“ extrahiert.

Durch Ermitteln der Inode-Nummer können Sie darauf zugreifen Informationsblöcke Datei (Schritte 7-11):

7. Die Gruppennummer, in der sich der angegebene Inode befindet, und seine Position in der Gruppen-Inode-Tabelle werden berechnet (vorausgesetzt, die Gruppennummer ist B und die Tabellenposition ist X).
8. Aus der Gruppendeskriptortabelle rufen wir den Deskriptor der Blockgruppe B ab und lesen daraus die Adresse der Inode-Tabelle dieser Blockgruppe.
9. Die Inode-Tabelle wird aus Blockgruppe B gelesen.
10. Aus der Inode-Tabelle der Blockgruppe B wird der Inode gelesen, der sich an Position X befindet.
11. Aus dem gelesenen Inode werden die Adressen des Blocks mit dem Inhalt der Datei /test.file extrahiert und Informationen aus dem Block mit der angegebenen Adresse gelesen.

Softwareimplementierung des Dateilesealgorithmus

Ausgangsdaten: Es gibt eine Festplattenpartition, auf der das ext2-Dateisystem erstellt wird. Dieser Abschnitt entspricht der Gerätedatei /dev/hda3. Im Stammverzeichnis der Partition wurde ein Unterverzeichnis home erstellt, in dem sich eine Datei test.file mit folgendem Inhalt befindet:

Würden Zitrusfrüchte im Dickicht des Südens leben?

Ja, aber eine gefälschte Kopie!

1234567890-=

Denken Sie nichts Schlimmes, das ist kein Unsinn, sondern eine Testübung aus dem Ausbildungslehrgang für Telegrafisten der Fernmeldetruppen der ehemaligen UdSSR!

Aufmerksamkeit! Eines ist zu beachten wichtiger Punkt. Die erstellte Datei wird nicht sofort auf die Festplatte geschrieben, sondern gelangt zunächst in den Festplattenpuffer. Ein Versuch, den Inhalt einer Datei mit dem oben genannten Algorithmus sofort abzurufen, führt zu nichts, da Informationen zu dieser Datei physisch nicht auf der Festplatte verfügbar sind. Es ist notwendig, das System zu „zwingen“, den Festplattenpuffer auf die Festplatte zu schreiben. Der einfachste Weg, dies zu tun, besteht darin, einen Neustart durchzuführen. Starten Sie daher nach dem Erstellen der Datei das System neu.

Unsere Aufgabe besteht darin, mithilfe der Gerätedatei /dev/hda3 die Datei /home/test.file zu lesen und dabei direkten Zugriff auf ihre Informationsblöcke zu nutzen.

Betrachten wir die Softwareimplementierung des Moduls, das diesen Vorgang ausführt.

Header-Dateien:

#enthalten

#enthalten

#enthalten

#enthalten

#enthalten

#enthalten

Die Header-Datei definiert Strukturtypen, die die Hauptkomponenten des ext2-Dateisystems beschreiben – Superblock, Blockgruppendeskriptor, Informationsknoten, Verzeichniseintrag.

Schauen wir uns kurz die Felder an, die in jeder dieser Strukturen enthalten sind:

1. Superblock-Struktur struct ext2_super_block:
   • __u32 s_inodes_count– Gesamtzahl der Inodes im Dateisystem;
   • __u32 s_blocks_count– die Gesamtzahl der Blöcke im Dateisystem;
   • __u32 s_free_blocks_count– Anzahl der freien Blöcke;
   • __u32 s_free_inodes_count– Anzahl der freien Inodes;
   • __u32 s_first_data_block– Nummer des ersten Datenblocks (Nummer des Blocks, in dem sich der Superblock befindet);
   • __u32 s_log_block_size– Dieser Wert wird zur Berechnung der Blockgröße verwendet. Die Blockgröße wird durch die Formel bestimmt: Blockgröße = 1024<< s_log_block_size;
   • __u32 s_blocks_per_group– Anzahl der Blöcke in der Gruppe;
   • __u32 s_inodes_per_group– Anzahl der Inodes in der Gruppe;
   • __u16 s_magic– Kennung des ext2-Dateisystems (Signatur 0xEF53);
   • __u16 s_inode_size– Größe des Informationsknotens (Inode);
   • __u32 s_first_ino– Nummer des ersten nicht reservierten Inodes.
2. Struktur des Blockgruppendeskriptors struct ext2_group_desc:
   • __u32 bg_block_bitmap– Belegungsbitmap von Gruppenblöcken;
   • __u32 bg_inode_bitmap– Inode-Gruppenbelegungs-Bitmap;
   • __u32 bg_inode_table– Adresse der Gruppen-Inode-Tabelle.
3. Die Struktur des Informationsknotens struct ext2_inode:
   • __u16 i_mode – Dateityp und Zugriffsrechte. Der Dateityp wird durch die Bits 12–15 dieses Felds bestimmt:
     • 0xA000- symbolischer Link;
     • 0x8000– reguläre Datei;
     • 0x6000– Gerätedatei blockieren;
     • 0x4000– Katalog;
     • 0x2000– Zeichengerätedatei;
     • 0x1000– FIFO-Kanal.
   • __u32 i_size– Größe in Bytes;
   • __u32 i_atime– Zeitpunkt des letzten Zugriffs auf die Datei;
   • __u32 i_ctime– Dateierstellungszeit;
   • __u32 i_mtime– Zeitpunkt der letzten Änderung;
   • __u32 i_blocks– die Anzahl der von der Datei belegten Blöcke;
   • __u32 i_block– Adressen von Informationsblöcken (einschließlich aller indirekten Links).

Der Wert von EXT2_N_BLOCKS ist in der Datei definiert:

* Konstanten relativ zu den Datenblöcken

#define EXT2_NDIR_BLOCKS 12

#define EXT2_IND_BLOCK EXT2_NDIR_BLOCKS

#define EXT2_DIND_BLOCK (EXT2_IND_BLOCK + 1)

#define EXT2_TIND_BLOCK (EXT2_DIND_BLOCK + 1)

#define EXT2_N_BLOCKS (EXT2_TIND_BLOCK + 1)

4. Verzeichniseintragsstruktur struct ext2_dir_entry_2:

#define EXT2_NAME_LEN 255

• __u32 Inode– Datei-Inode-Nummer;
• __u16 rec_len– Länge des Verzeichniseintrags;
• __u8 name_len– Länge des Dateinamens;
• Char-Name – Dateiname.

Bestimmen wir den Namen der Partition, auf der das Dateisystem erstellt wird, globale Strukturen und Variablen.

#define PART_NAME „/dev/hda3“

struct ext2_super_block sb;

/* Puffer zum Speichern der Gruppendeskriptortabelle */

unsigned char buff_grp;

unsignierter Char-Buff; /* Informationspuffer */

int indev; /* Gerätedateideskriptor */

int BLKSIZE; /* Blockgröße des Dateisystems */

Definieren wir mehrere Funktionen, die wir für die Arbeit benötigen:

Superblock-Lesefunktion:

void read_sb()

Memset(&sb,0.1024);

Wir verschieben 1024 Bytes vom Anfang des Abschnitts und lesen den Superblock in die Struktur struct ext2_super_block sb ein:

If(lseek(indev,1024,0)< 0) {

Perror("lseek");

Ausgang(-1);

If(read(indev,(char *)&sb,sizeof(sb))< 0) {

Perror("read");

Ausgang(-1);

Überprüfung der Dateisystem-ID:

If(sb.s_magic != EXT2_SUPER_MAGIC) (

Printf("Unbekannter Dateisystemtyp!");

Ausgang(-1);

Der EXT2_SUPER_MAGIC-Wert ist in der Header-Datei definiert.

Wir zeigen Informationen über das Dateisystem an, das sich im Superblock befindet:

printf(" Superblock-Info ----------- ");

Printf("Inodes count - %u ",sb.s_inodes_count);

Printf("Blocks count - %u ",sb.s_blocks_count);

Printf("Blockgröße - %u ",1024<< sb.s_log_block_size);

Printf("Erster Inode - %d ",sb.s_first_ino);

Printf("Magic - 0x%X ",sb.s_magic);

Printf("Inode-Größe - %d ",sb.s_inode_size);

Printf("Inodes pro Gruppe - %u ",sb.s_inodes_per_group);

Printf("Blosks pro Gruppe - %u ",sb.s_blocks_per_group);

Printf("Erster Datenblock - %u ",sb.s_first_data_block);

Zurückkehren;

Lesefunktion der Gruppendeskriptortabelle:

void read_gdt()

Berechnen Sie die Blockgröße des Dateisystems:

BLKSIZE = 1024<< sb.s_log_block_size

Die Gruppendeskriptortabelle befindet sich in dem Block, der sich unmittelbar nach dem ersten Datenblock (hinter dem Superblock) befindet.

Lesen der Tabelle:

If(lseek(indev, (sb.s_first_data_block + 1) * BLKSIZE, 0)< 0) {

Perror("lseek");

Ausgang(-1);

If(read(indev,buff_grp,BLKSIZE)< 0) {

Perror("read");

Ausgang(-1);

Zurückkehren;

Funktion zum Abrufen des Inhalts eines Inodes anhand seiner Nummer:

void get_inode(int inode_num, struct ext2_inode *in)

Die Eingabeparameter der Funktion sind die Inode-Sequenznummer und die Struktur struct ext2_inode.

Struct ext2_group_desc gd;

U64-Gruppe, Index, Pos;

Wir berechnen die Nummer der Blockgruppe, in der sich der Inode mit der Seriennummer inode_num befindet:

Group = (inode_num - 1) / sb.s_inodes_per_group;

Extrahieren Sie aus der Gruppendeskriptortabelle den Gruppendeskriptor und kopieren Sie ihn in die GD-Struktur struct ext2_group_desc:

Memset((void *)&gd, 0, sizeof(gd));

Memcpy((void *)&gd, buff_grp + (group * (sizeof(gd))), sizeof(gd));

Wir berechnen die Position des Inodes mit der Seriennummer inode_num in der Inode-Tabelle der Gruppe group und lesen diesen Inode in die Struktur struct ext2_inode ein:

index = (inode_num - 1) % sb.s_inodes_per_group;

Pos = ((__u64)gd.bg_inode_table) * BLKSIZE + (index * sb.s_inode_size);

Pread64(indev, in, sb.s_inode_size, pos);

Zurückkehren;

Funktion zum Lesen von Datenblöcken:

void read_iblock(struct ext2_inode *in, int blk_num)

U64 pos;

Die Eingabeparameter der Funktion sind die Inode-Struktur und die Blocknummer (gemeint ist die Nummer aus der Folge der im Inode befindlichen Adressblöcke).

Wir berechnen den Offset zum Informationsblock auf dem Abschnitt und lesen diesen Block in den globalen Buff-Puffer:

Pos = ((__u64)in->i_block) * BLKSIZE;

Pread64(indev, buff, BLKSIZE, pos);

Zurückkehren;

Funktion zum Abrufen des Inhalts des Stammverzeichnisses:

void get_root_dentry()

Struct ext2_inode in;

Die Inode-Nummer des Stammverzeichnisses ist bekannt, daher erhalten wir den Inhalt des Inodes des Stammverzeichnisses und lesen seinen Inhalt in den Buff-Puffer:

get_inode(EXT2_ROOT_INO, &in);

Read_iblock(&in, 0);

Der Buff-Puffer enthält den Inhalt des Stammverzeichnisses.

Zurückkehren;

Funktion zum Abrufen der Inode-Nummer anhand des Dateinamens:

int get_i_num(char *name)

Die Eingabeparameter der Funktion sind der Dateiname. Der Rückgabewert ist die Inode-Nummer der Datei.

Int i = 0, rec_len = 0;

Struct ext2_dir_entry_2 dent;

Der Buff-Puffer enthält ein Array von Verzeichniseinträgen. Um die Inode-Nummer einer Datei zu ermitteln, müssen Sie in diesem Array einen Eintrag mit dem Namen dieser Datei finden:

Für(; ich< 700; i++) {

Memcpy((void *)&dent, (buff + rec_len), sizeof(dent));

If(!memcmp(dent.name, name, dent.name_len)) break;

Rec_len += dent.rec_len;

Return dent.inode;

Schreiben wir nun die Hauptfunktion:

int main()

Variablen und Strukturen:

struct ext2_inode in;

// absoluter Pfadname der Datei

Unsigned char *full_path = "/home/test.file";

Unsigned char buff1;

Statisch int i = 1;

Int n, i_num, outf, type;

Das erste Zeichen in einem absoluten Pfadnamen einer Datei muss ein Schrägstrich (/) sein. Lassen Sie uns Folgendes überprüfen:

If(full_path != "/") (

Perror("Schrägstrich");

Ausgang(-1);

Öffnen Sie die Gerätedatei, lesen Sie den Superblock und die Gruppendeskriptortabelle:

Indev = open(PART_NAME,O_RDONLY);

Wenn(indiv< 0) {

Perror("open");

Ausgang(-1);

Read_sb();

Read_gdt();

Wir erhalten den Inhalt des Stammverzeichnisses:

get_root_dentry();

Jetzt enthält der Buff-Puffer alle Einträge im Stammverzeichnis (Sie können sie bei Bedarf in einer separaten Datei speichern). Anhand der Stammverzeichniseinträge können wir nun mit dem oben genannten Dateilesealgorithmus auf den Inhalt von test.file zugreifen. Zu diesem Zweck organisieren wir einen Zyklus. Im Hauptteil der Schleife analysieren wir den absoluten Pfadnamen der Datei und heben ihre Elemente hervor – Unterverzeichnisse (wir haben nur eines, home) und den Namen der gesuchten Datei (test.file). Für jedes Element ermitteln wir die Inode-Seriennummer, zählen diesen Inode und erhalten dann den Inhalt des Nullblocks (aus der Folge der im Inode befindlichen Adressblöcke):

while(1) (

Memset(buff1,0,sizeof(buff1));

For(n = 0 ; n< EXT2_NAME_LEN; n++, i++) {

Buff1[n] = full_path[i];

If((buff1[n] == "/") || (buff1[n] == "?")) (

I++;

Brechen;

buff1[n] = "?";

Für jedes Element des absoluten Pfadnamens der Datei ermitteln wir die Inode-Sequenznummer, lesen diesen Inode in den Speicher und erhalten dann den Inhalt des Nullblocks:

I_num = get_i_num(buff1);

Get_inode(i_num, &in);

Read_iblock(&in, 0);

Lassen Sie uns Informationen zur Datei anzeigen (Name, Inode-Nummer, Dateigröße und -typ):

Printf("Inode-Nummer - %u", i_num);

Printf("Dateiname - %s ", buff1);

Printf("Dateigröße - %u ",in.i_size);

Der Dateityp wird durch die höchsten vier Bits des i_mode-Felds der Struktur struct ext2_inode bestimmt:

type = ((in.i_mode & 0xF000) >> 12);

Printf("Typ - %d ",type);

Schalter(Typ) (

Fall(0x04):

Printf("(Verzeichnis) ");

Brechen;

Fall(0x08):

Printf("(reguläre Datei) ");

Brechen;

Fall(0x06):

Printf("(Gerätedatei blockieren) ");

Brechen;

Fall(0x02):

Printf("(Zeichengerätedatei) ");

Brechen;

Standard:

Printf("(unbekannter Typ) ");

Brechen;

Überprüfen des Dateityps. Wenn es sich um eine reguläre Datei handelt, unterbrechen wir die Schleife:

If(Typ & 0x08) (

Der Buff-Puffer enthält Informationen, die aus den Informationsblöcken der Datei /home/test.file gelesen werden. Schreiben wir diese Informationen in eine Datei:

Outf = open("out",O_CREAT|O_RDWR,0600);

Write(outf, buff, sizeof(buff));

Close(outf);

Brechen;

Wir verlassen:

Close(indev);

Rückgabe 0;

Damit ist unsere Betrachtung der logischen Struktur des ext2-Dateisystems abgeschlossen.