diff --git a/Writerside/images/image_351.png b/Writerside/images/image_351.png new file mode 100644 index 0000000..7ec11f1 Binary files /dev/null and b/Writerside/images/image_351.png differ diff --git a/Writerside/images/image_352.png b/Writerside/images/image_352.png new file mode 100644 index 0000000..a55bf22 Binary files /dev/null and b/Writerside/images/image_352.png differ diff --git a/Writerside/images/image_353.png b/Writerside/images/image_353.png new file mode 100644 index 0000000..a55bf22 Binary files /dev/null and b/Writerside/images/image_353.png differ diff --git a/Writerside/images/image_354.png b/Writerside/images/image_354.png new file mode 100644 index 0000000..b7a800f Binary files /dev/null and b/Writerside/images/image_354.png differ diff --git a/Writerside/images/image_355.png b/Writerside/images/image_355.png new file mode 100644 index 0000000..8e76cb9 Binary files /dev/null and b/Writerside/images/image_355.png differ diff --git a/Writerside/images/image_356.png b/Writerside/images/image_356.png new file mode 100644 index 0000000..8e76cb9 Binary files /dev/null and b/Writerside/images/image_356.png differ diff --git a/Writerside/images/image_357.png b/Writerside/images/image_357.png new file mode 100644 index 0000000..227b436 Binary files /dev/null and b/Writerside/images/image_357.png differ diff --git a/Writerside/images/image_358.png b/Writerside/images/image_358.png new file mode 100644 index 0000000..33cc2e9 Binary files /dev/null and b/Writerside/images/image_358.png differ diff --git a/Writerside/images/image_359.png b/Writerside/images/image_359.png new file mode 100644 index 0000000..67300e3 Binary files /dev/null and b/Writerside/images/image_359.png differ diff --git a/Writerside/topics/BS/16_Dateisysteme.md b/Writerside/topics/BS/16_Dateisysteme.md index 0f512f0..0b8ec28 100644 --- a/Writerside/topics/BS/16_Dateisysteme.md +++ b/Writerside/topics/BS/16_Dateisysteme.md @@ -154,6 +154,157 @@ - Spitze des Dateibaums - ![image_340.png](image_340.png) -### Methoden zur Belegungsverkettung -#### Zusammenhängende Belegung +## Methoden zur Belegungsverkettung +### Zusammenhängende Belegung +- Einfachstes Belegungsschema +- Speicherung als zusammenhängende Menge von Plattenblöcken + - Jede Datei beginnt mit neuem Block +- ![image_351.png](image_351.png) +- | Vorteile | Nachteile | + |-----------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------| + | Einfach zu implementieren
Lokalisierung der Dateiblöcke basiert auf zwei Zahlen | Im Laufe der Zeit wird die Platte fragmentiert | + | hervorragende Leseleistung
Gesamte Datei kann mit einer Operation von der Platte gelesen werden | ![image_352.png](image_352.png) | +- In manchen Situationen praktikabel + - CD-ROM + - alle Dateigrößen sind bekannt, werden sich niemals während Gebrauch ändern + - DVD + - Kann als eine Datei gespeichert werden + - meistens ~4 1GB Dateien + +### Verkettete Listen +- Jede Datei ist verkettete Liste von Plattenblöcken + - Erstes Wort = Zeiger auf den nächsten + - Rest = Daten +- ![image_353.png](image_353.png) +- | Vorteile | Nachteile | + |-------------------------------------------------------------------------|--------------------------------------------------------------------| + | Kein verlorener Speicherplatz durch Fragmentierung | sequenzielles Lesen zwar schnell, wahlfreier Zugriff sehr langsam | +| | Für Verzeichniseintrag ist Plattenadresse des ersten Blocks ausreichend | Um Auf Block n zuzugreifen müssen n-1 Blöcke vorher gelesen werden | + +### File Allocation Table (FAT) +- Zeiger jedes Plattenblocks in einer Tabelle im Arbeitsspeicher +- | Vorteile | Nachteile | + |------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------| + | Gesamter Block steht für Daten zur Verfügung | Gesamte Tabelle muss durchgehend im Speicher sein | + | Obwohl Kette verfolgt werden muss, kann das im RAM ohne Zugriffe auf Platte geschehen | Bei einer !TB Festplatte mit einer Blockgröße von 1KB benötigt die Tabelle 1Mia*3Byte ~ 3GB des RAM | + | Es reicht für Verzeichniseintrag einen einzigen ganzzahligen Wert des Startblocks zu speichern | | + +### I-Nodes (Index Node) +- Datenstruktur, die Informationen über eine Datei oder ein Verzeichnis auf einem Dateisystem enthält + - Jede/s Datei/Verzeichnis ist durch einen eindeutigen I-Node identifiziert +- | Vorteile | Nachteile | + |--------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------| + | I-Node muss nur im Speicher sein, solange Datei geöffnet ist | Jeder Node kann nur begrenzte Anzahl von Plattenadressen
Sobald das Limit erreicht ist, müsste man die letzte Adresse als Zeiger auf den nächsten Node nehmen | + | Feld, das die I-Nodes enthält benötigt nur n*k Byte | | +- ![image_354.png](image_354.png) + + +## Dateinamen +- Keine festgelegte Länge + - variable Dateinamenlängen verwalten? + - ![image_355.png](image_355.png) + - Nachteil: + - Lücke variabler Länge + - entsteht, wenn eine Datei entfernt wird und nächste Lücke nicht genau passt + - Es ist möglich Verzeichniseinträge zu verschieben + - ![image_356.png](image_356.png) + - Für alle Dateinamen nur feste Längen zulassen + - Gemeinsam auf einem Heap am Ende des Verzeichnisses speichern + - Vorteil: + - nach Entfernen einer Datei passt nächste immer rein + - Heap muss mitverwaltet werden :/ + - Lineare Suche → sehr langsam + - Verwendung einer Hashtabelle in jedem Verzeichnis + - Vorteil einer viel schnelleren Suche + - Nachteil: komplizierte Verwaltung + - Zwischenspeichern der Resultate vorangegangener Suchen + +## Gemeinsam genutzte Dateien +- ![image_357.png](image_357.png) +- Probleme: + - ![image_358.png](image_358.png) + - Enthält Verzeichnis Plattenadressen, dann muss Kopie der Adressen im Verzeichnis B angelegt werden + - Wenn B/C Daten an Datei anhängen + - neue Blöcke werden nur im Verzeichnis, in dem Änderung stattfand, aufgelistet + - Zweck gemeinsamer Verwendung verfehlt + +### Symbolische Links +- Enthält Pfadnamen zur gewünschten Datei +- Wenn B Datei liest, sucht BS direkt im angegebenen Pfad +- | Vorteil | Nachteile | + |--------------------------------------------------------|--------------------------------------------------------------------------------------------| + | Dateien auf entfernten, vernetzten Maschinen verlinken | zusätzlicher Aufwand
eigener Plattenblock für Pfad | + | | Datei mit Pfadnamen muss gelesen werden, Pfad analysieren, Komponente bis I-Node verfolgen | + | | Falls in Unterverzeichnissen wird Datei evtl. mehrfach gefunden | + | | Bei Einspielung auf anderen Computer → Link wird zur Kopie der selben Datei | + +## Log-basiertes Dateisystem (LFS) +- Schreibzugriffe sind effizienter als Lesezugriffe +- Schreibleistungs- und Fragmentierungsprobleme überwinden + - Schreibvorgänge werden protokolliert +- Mit schnelleren CPUs, größerem RAM wächst Platten-Cache schneller + - Viele Lesezugriffe direkt aus Platten-Cache + - Ohne Festplattenzugriffe + - Meiste Plattenzugriffe = Schreibzugriffe :) +- Probleme + - Schreibzugriffe meist in Stückchen → ineffektiv + - Abhängig von + - Spurwechselzeit ([seek](#seek) time) + - Latenzzeit (latency) + - Kommando-Latenz (controller overhead) + - Inkonsistenzen bei Systemabstürzen +- Lösungsansatz + - Alle noch ausstehenden im Speicher gepufferten Schreibaufträge regelmäßig sammeln + - An Ende des Logs schreiben + - Einzelnes Segment kann in beliebiger Reihenfolge I-Nodes, Verzeichnisblöcke und Datenblöcke enthalten + - Am Anfang Zusammenfassung über Inhalt +- Probleme Lösungsansatz + - Log wird ohne Reorganisation immer größer + - Bereinigungsvorgang wird benötigt + - Über alle Vorgänge Protokoll zu führen erfordert logistischen Aufwand + - LFS sind hochgradig inkompatibel zu bestehenden Dateisystemen + - können Inkonsistenz bei Systemabstürzen nicht abfangen + +## Journaling +- mit Grundgedanken von [LFS](#log-basiertes-dateisystem-lfs) Robustheit DS erhöhen + - Log ist Protokoll über geplante Aktionen +- Bei Systemabsturz vor Beendigung einer geplanten Arbeit + - Bei Neustart im Log nachschauen, was gerade vor sich ging + - Vorgang sauber beenden +- Beispiel: + - _NTFS_, _ext3_, _macOS Extended_ +- Für zusätzliche Zuverlässigkeit + - Datenbankkonzept der atomaren Transaktion + - Gruppe von Aktionen klammern + - Anfangstransaktion (begin transaction) + - Endtransaktion (end transaction) + - Dateisystem weiß, das es alle eingeklammerten oder keine ausführen muss + - ACID-Eigenschaften + - **Atomarität (Atomicity)** + - Transaktion wird als Ganzes behandelt + - alle oder keine Operationen in Transaktion ausführen + - Wenn eine fehlschlägt Rest rückgängig machen + - **Konsistenz (Consistency)** + - Transaktionen werden von einem in einen andern konsistenten Zustand überführt + - Nach Abschluss einer erfolgreichen Transaktion + - DB in Zusatnd, der Integritätsregeln entspricht + - **Isolation (Isolation)** + - mehrere gleichzeitige Transaktionen unabhängig, gleichzeitig ausführen + - **Dauerhaftigkeit (Durability)** + - einmal abgeschlossene Transaktion dauerhaft in DB gespeichert + - Änderung auch nach Systemabsturz / Neustart erhalten + +## Virtuelle Dateisysteme (VFS) +- ![image_359.png](image_359.png) +- Abstraktionsschicht im BS + - dient zur Vereinheitlichung der Dateisysteme und deren Zugriffsmethoden +- Anwendungen können auf Dateien zugreifen + - ohne auf Details der zugrunde liegenden physischen Dateisysteme zu achten + - erleichtert Portabilität, flexiblere Verwaltung der Dateisystemressourcen +- Wenn System hochgefahren + - Wurzeldateisystem beim VFS registrieren + - Liste der Adressen von Funktionen dem VFS zur Verfügung stellen + - Entweder lange Aufruftabelle oder eine Tabelle pro VFS-Objekt + - VFS legt im RAM V-Nodes an + - weitere Dateisysteme jetzt oder während Ausführung