 |
powered by 
|
| Nachrichten | Lexikon | Protokolle | Bücher | Foren | Mittwoch, 19. Juni 2013 |
Ext2Dieser Artikel von Wikipedia ist u.U. veraltet. Die neue Version gibt es hier. Das ext2 oder auch Second extended Filesytem war viele Jahre lang das Standard dateisystem des Linux -Betriebssystems und ist immer noch weit verbreitet. wurde ursprünglich 1993 von Rémy Card auf Basis des Filesystem v1 entwickelt die heutige Implementation im Linux-Kernel stammt sowohl von ihm als auch Ts'o und Stephen Tweedie. Desweiteren existieren Implementationen NetBSD FreeBSD GNU HURD Microsoft Windows OS/2 und RISC OS . Hauptnachteil von ext2 ist dass es Journaling-Dateisystem ist. Es verliert daher zunehmend Benutzer ReiserFS und an seinen abwärtskompatiblen Nachfolger ext3 . ext3 wird in diesem Artikel weiter besprochen.
Spezifikationext2 teilt viele seiner Eigenschaften mit Unix -Filesystemen z. B. das Konzept der Blöcke Inodes und Verzeichnisse. Wenn gewünscht ist es Eigenschaften wie Zugriffskontrollisten ( ACLs ) Fragmente Wiederherstellung gelöschter Daten und Kompression erweiterbar. Die meisten der genannten Funktionen nicht serienmäßig implementiert sondern existieren nur als Patches . Weiterhin gibt es einen Versionsmechanismus der erlaubt neue Funktionen abwärtskompatibel hinzuzufügen (wie dies der Journaling-Erweiterung ext3 geschehen ist). Alle Informationen auf einem ext2-System im " Little Endian "-Format abgelegt so dass ein Dateisystem auf Architekturen eingehängt werden kann ohne dass plötzlich Leserichtung nicht mehr stimmt.
BlöckeDer Platz auf einem mit ext2 Gerät oder Datei (man kann ext2-Systeme in ablegen die wiederum auf anderen Dateisystemen liegen) in Blöcke aufgeteilt. Diese haben eine feste von 1 kB 2 kB oder 4 (8 kB auf Alphaarchitekturen). Die Größe der wird bei der Erstellung des Dateisystems festgelegt. Blöcke führen zu weniger verschwendetem Platz pro benötigen aber etwas mehr Overhead bei der und begrenzen indirekt auch die maximale Größe Dateien und dem ganzen Dateisystem.
BlockgruppenBlöcke werden in Blockgruppen zusammengefasst um zu reduzieren und den Zugriff auf große aufeinander folgender Daten zu beschleunigen indem die Kopfbewegungen der Festplatte minimiert werden. Die Informationen jede Blockgruppe werden in einer Deskriptortabelle abgelegt direkt hinter dem Superblock liegt. Zwei Blöcke der Nähe des Beginns der Blockgruppe sind zwei Bitmaps reserviert die die Block- und Inode -Belegung in der Gruppe anzeigen. Da jedes nur einen Block belegen kann ist die Größe jeder Blockgruppe auf achtmal die Größe Blockes begrenzt. Die auf die Bitmaps folgenden fungieren als Inode-Tabelle für die Blockgruppe und übrigen sind als Datenblöcke nutzbar.
Der SuperblockDer Superblock enthält alle Informationen über Konfiguration des Dateisystems. Der primäre Superblock liegt Byte hinter dem Beginn des Gerätes und wichtig um das Dateisystem einbinden ( mount ) zu können. Weil er so wichtig werden Sicherungskopien dieses Blocks in mehreren Blockgruppen Dateisystem angelegt. Die Informationen im Superblock enthalten die z. B. die Anzahl der Blöcke Inodes im Dateisystem angeben wie viele davon sind wie viele Inodes und Blöcke in Blockgruppe vorhanden sind wann das Dateisystem eingebunden ob es beim letzten Mal auch wieder ausgehangen wurde wann es geändert wurde welche vorliegt und welches Betriebssystem es angelegt hat.Wenn das Dateisystem Revision 1 oder ist gibt es im Superblock weitere Felder den Namen des Datenträgers eine eindeutige Identifikationsnummer die Inode-Größe angeben sowie Platz für die optionaler Dateisystemfunktionen bieten.
InodesDer Inode (Indexknoten) ist ein fundamentales Konzept im Jedes Objekt im Dateisystem wird durch einen repräsentiert. Die Inode-Struktur enthält Zeiger (Verweise) auf Blöcke in denen die Daten des Objekts sind und außerdem alle Metadaten über ein Objekt mit Ausnahme seines Zu den Metadaten gehören Zugriffsrechte Besitzer Gruppe Größe die Anzahl der benutzten Blöcke Zugriffszeitpunkt Löschzeitpunkt Anzahl der Links Fragmente Version (wird NFS benötigt) erweiterte Attribute und eventuelle ZugriffskontrollistenEs gibt einige ungenutzte Felder und Felder in der Inode-Struktur. Ein Feld ist die Verzeichnis-ACL reserviert wenn der Inode ein ist alternativ hält dieses Feld die oberen Bit der Dateigröße wenn der Inode eine Datei ist (dies erlaubt Dateigrößen > 2 Die meisten der übrigen Felder werden von Linux und HURD als vergrößerte Besitzer- und Gruppenfelder genutzt. kennt außerdem zusätzliche Felder für erweiterte Rechteverwaltung den Inode des Programms das diesen Inode interpretiert. Es gibt im Inode-Zeiger auf die 12 Blöcke die die Daten der Datei Außerdem gibt es einen Zeiger auf einen Block (der wiederum Zeiger auf den nächsten von Blöcken der Datei enthält) einen Zeiger einen doppelt indirekten Block (der Zeiger auf indirekte Blöcke enthält) und einen Zeiger auf dreifach indirekten Block (der Zeiger auf doppelt Blöcke enthält). Das Flags -Feld enthält einige ext2-spezifische flags die nicht durch chmod etc. beeinflusst werden können. Diese Flags mit lsattr gelistet werden und mit chattr geändert werden und erlauben einer Datei Verhalten. Es gibt flags für sicheres Löschen Unlöschbarkeit Kompression synchrone Schreibschutz indexierte Verzeichnisse Journaling und einiges mehr. alle flags lassen sich derzeit sinnvoll verwenden.
VerzeichnisseEin Verzeichnis ist ein Dateisystemobjekt und wie eine normale Datei einen Inode. Prinzipiell es eine spezielle Datei die jeden Dateinamen Verzeichnis mit einer Inode-Nummer verknüpft. Neuere Versionen Dateisytems legen auch den Typ des Objektes Verzeichnis Symlink Gerät FIFO Socket ) mit ab um zu vermeiden dass Inode selbst auf diese Information geprüft werden (um dies nutzen zu können ist eine Version der glibc erforderlich).
Spezielle DateienSymbolische Links ( Symlinks ) sind ebenfalls Dateisystemobjekte mit Inodes. Wenn Symlink allerdings kürzer als 60 Bytes ist seine Daten direkt im Inode gespeichert. Dabei Felder benutzt die normalerweise Zeiger auf Datenblöcke würden. Da die meisten Symlinks weniger als Zeichen lang sind spart man hierdurch die Inanspruchnahme eines Blocks für den Symlink.Zeichen- und blockorientierte Geräte haben nie zugewiesen. Stattdessen wird die vom Kernel vergebene im Inode abgelegt wobei wiederum die Zeigerfelder Datenblöcke benutzt werden.
Reservierter SpeicherplatzInnerhalb des Dateisystems lässt sich eine Anzahl von Blöcken für einen bestimmten Benutzer den Systemadministrator ( root )). Dies erlaubt dem System auch dann funktionieren wenn nichtprivilegierte Benutzer den gesamten ihnen Verfügung stehenden Speicherplatz aufgefüllt haben. Der Mechanismus unabhängig von Dateisystem quotas . Weiterhin hilft er dabei ein vollständiges des Dateisystems zu verhindern und so Fragmentierung bekämpfen.
DateisystemüberprüfungWährend der Startphase führen die meisten eine Konsistenzüberprüfung ( e2fsck ) auf ihren Dateisystemen durch. Der Superblock ext2-Systems enthält mehrere Felder die anzeigen ob fsck laufen sollte (da die Prüfung des lange dauern kann wenn es sehr groß fsck wird üblicherweise laufen wenn das Dateisystem sauber ausgehangen wurde oder eine einstellbare Maximalzeit zwei Routineüberprüfungen überschritten wurde.
Kompatibilitätext2 verfügt über einen ausgreiften Kompatibilitätsmechanismus es erlaubt Dateisysteme unter Kernels zu verwenden deren ext2fs-Treiber von einigen Funktionen nichts weiß. Der Kompatibilitätsmechanismus steht seit Revision 1 zur Verfügung. Es gibt dabei Felder von je 32 Bit Länge eines kompatible Eigenschaften (COMPAT) eines für nur lesekompatible (RO_COMPAT) und eines für inkompatible Eigenschaften (INCOMPAT).Ein COMPAT- flag bedeutet dass das Dateisystem eine Eigenschaft aber das Datenformat auf der Platte 100 kompatibel mit älteren Formaten ist so dass Kernel der diese Funktion nicht kennt im lesen und schreiben könnte ohne es inkonsistent machen. Bestes Beispiel für ein COMPAT- flag ist die Funktion HAS_JOURNAL eines ext3-Dateisystems. Kernel ohne ext3-Unterstützung kann ein solches Dateisystem als ext2fs einhängen und dann quasi unter des Journals darauf schreiben ohne irgendetwas zu Ein RO_COMPAT- flag zeigt an dass das Datenformat des beim Lesen 100 % kompatibel zu älteren ist. Ein Kernel ohne Kenntnis der in stehenden Funktion könnte jedoch das Dateisystem korrumpieren er darauf schreibt daher wird dies verhindert. Beispiel für eine lesekompatible Eigenschaft ist SPARSE_SUPER Dateisystemlayout bei dem weniger Superblocksicherungen als normal auf dem Datenträger abgelegt werden. Ein alter kann problemlos von einer solchen Festplatte lesen er jedoch einen Schreibversuch unternehmen würde würden Schreibroutinen irreführende Fehlermeldungen produzieren und evtl. die inkonsistent werden. Ein INCOMPAT- flag zeigt an dass sich das Datenformat geändert hat dass Kernels ohne diese Eigenschaft schreiben noch lesen oder auch nur einhängen Als Beispiel für eine inkompatible Zusatzfunktion kann optionale Kompression dienen; Ein Kernel der die nicht dekomprimiert würde nur "Müll" vom Datenträger Auch ein inkonsistenstes ext3-Dateisystem ist so lange bis ein ext3-fähiger Kernel das Journal abgespielt und die Inkonsistenzen beseitigt hat. Danach kann ext3-System auch wieder als ext2 eingehangen werden. Das Hinzufügen neuer Eigenschaften zum ext2/3-Dateisystem auch immer eine Aktualisierung des zugehörigen toolkit e2fsprogs da die darin enthaltenen Prüfungswerkzeuge in Lage sein müssen alle Dateisystemeigenschaften zu kennen eine zuverlässige Feststellung und Behebung von Inkonsistenzen ermöglichen.
Dateisystemgrenzen
Die in der nebenstehenden Tabelle genannten für Dateigrößen haben eher akademischen Wert da Beispiel der Linux-Kernel 2.4 keine Dateien > 2 GB und Blockgrößen von 8 kB sind standardmäßig auf Alpha-Architekturen möglich sowie auf speziell konfigurierten gepatchten anderen Architekturen. Das Dateisystem begrenzt die Anzahl von in einem gegebenen Verzeichnis auf 32.768 Stück. wird angewarnt wenn in einem Verzeichnis mehr ca. 10.000-15.000 Dateien liegen da Dateioperationen in großen Verzeichnissen lange dauern können. Die tatsächlich mögliche Anzahl von Dateien ist wieder akademischer da man Schwierigkeiten haben wird genügend eindeutige zu finden bevor man an das Limit 130 Trillionen Dateien pro Verzeichnis stößt. Handhabbar solche Verzeichnisse ohnehin nicht mehr.
ext3Journaling mit ext3fsDie von Stephen Tweedie entwickelte Journalingerweiterung für ext2 sorgt dafür dass Metadaten mehr korrumpiert werden können und dass auf kompletten Durchlauf von e2fsck nach einem Rechnerabsturz verzichtet werden kann. solches Dateisystem wird meist als ext3-Dateisystem bezeichnet. Datenformat des Datenträgers ändert sich bei Verwendung Journals nicht. Das Journal ist eine reguläre in die die Metadaten (optional auch die geschrieben werden bevor sie auf das tatsächliche geschrieben werden. Aus einem ext2- kann man ein ext3-Dateisystem machen ohne irgendwelche Daten konvertieren müssen.Wenn eine Änderung am Dateisystem (z. die Umbenennung einer Datei) durchgeführt wird wird als Transaktion im Journal vermerkt und kann dann Fall eines Absturzes entweder abgeschlossen oder noch abgeschlossen sein. Wenn eine Transaktion zum Absturzzeitpunkt im Normalfall wenn das System nicht abstürzt) war ist garantiert dass alle an dieser beteiligten Blöcke einen gültigen Dateisystemstatus repräsentieren. Diese werden dann ins Dateisystem kopiert. Wenn eine zum Absturzzeitpunkt nicht abgeschlossen war kann nicht werden dass die beteiligten Blöcke konsistent sind wird eine solche Transaktion verworfen (das bedeutet die Dateisystemänderung die diese Transaktion repräsentierte verloren Bei abgebrochenen Schreiboperationen kann es passieren ein Teil einer Datei bereits aus den Daten besteht und ein Teil noch aus alten was manchmal noch schlimmer sein kann ein inkonsistentes Dateisystem. ext3 bietet daher einen Modus in dem auch Daten zunächst im abgelegt werden. ext3 schützt nicht davor dass verloren gehen die zum Absturzzeitpunkt zwar eigentlich auf die Platte geschrieben sein sollten vom jedoch noch in so genannten schmutzigen Puffern gehalten wurden um sie später zurückzuschreiben. dem Abspielen des Journals ist nur garantiert man mit einem konsistenten Datenbestand zu einem Zeitpunkt weiterarbeiten kann.
Weblinks
| ||||||||||||||||||
| Impressum • Lesezeichen setzen • Seite versenden • Seite drucken |
<a href="http://www.uni-protokolle.de/Lexikon/Ext2.html">Ext2 </a>