H.-A. Schindler Kapitel 4: Dateisysteme · Schindler Folie: 1 -2 Roadmap Betriebs-system Anwendungsschnittstelle (Application Programmer‘s Interface, API) Anwen-dungs-ebene GUI

Kapitel 4:

Dateisysteme

Wintersemester 2019/20

Betriebssysteme

H.-A. Schindler

Betriebssysteme: ws 2019/20 H.-A. Schindler Folie: 1 - 2

Roadmap

Betriebs-

system

Anwendungsschnittstelle (Application Programmer‘s Interface, API)

Anwen-

dungs-

ebene

OfficeGUI Google Earth

ABSMatLab Firefox

Betriebssystem-Dienste

Prozessmanagement Dateisysteme Netzwerkmanagement

Ressourcenmanagement

Prozessor-

Ressourcen

Kommunikations-

Ressourcen

Speicher-

RessourcenE/A

Ressourcen

4. Dateisysteme


Dateien und Dateisysteme

Motivation

Prozesse

verarbeiten Informationen,

speichern diese,

rufen diese ab,

• deren Lebenszeit >> Lebenszeit Prozesse → Persistenz

• deren Datenvolumen >> Arbeitsspeicher → Größe

• zur gemeinsamen Nutzung → individuelle Zugriffsrechte

benötigt wird: geeignetes Paradigma

• Datei: Betriebssystem-Abstraktion zum Management persistenter Daten

• Dateisystem: „Aktenschrank“, der Dateien enthält

4. Dateisysteme


4.1 Dateimodelle

Aufgabe

Präzise Festlegung der Semantik der Abstraktion „Datei“

Varianten

... gibt es viele

diese unterscheiden sich durch

1. Dateinamen; z.B.

Typtransparenz („kap4.pptx“ vs. „kap4“)

Ortstransparenz („C:\Users\maier“ vs. „/Users/maier“)

Struktur (flach, hierarchisch)

2. Dateiattribute; z.B.

Sicherheitsattribute,

Zugriffsstatistiken

3. Operationen auf Dateien

Erzeugen,

Löschen,

Lese/Schreiboperationen

4. Dateisysteme / 4.1 Dateimodelle


Aufgabe

Identifikation von Dateien mittels symbolischer Namen

Namensmerkmale

1. Grundmerkmale

• verwendbare Zeichen, Groß/Kleinschreibungssensitivität,

Längenbeschränkungen, ...

2. Typtransparenz

• Windows-Familie: explorer.exe, kap4.pdf, LadyInBlack.flac

• Unix-Familie: explorer, kap4, LadyInBlack

3. Ortstransparenz

• Windows: C:\Users\maier

• Mac OS X, Linux: /Users/maier

4. Namensstruktur →

4.1.1 Dateinamen

4. Dateisysteme / 4.1 Dateimodelle / 4.1.1 Dateinamen


Hierarchischer Namensraum

Kennen wir schon; z.B.

Postadressen: Land/Stadt/Straße/Hausnummer/Name

→

große Dateianzahlen: Beherrschbarkeit

1. Eindeutigkeit

vorlesungen/bs/kap1 vs. vorlesungen/va/kap1

2. Eingrenzung von Sichten (Mehrbenutzersysteme)

/Users/schindler vs. /Users/amthor

Darstellung: baumartige Strukturen

• „Pfadnamen“ = Pfade im Namensraum

Users

amthor schindler

vorlesungen

Dateinamen

4. Dateisysteme / 4.1 Dateimodelle / 4.1.1 Dateinamen


4.1.2 Dateistrukturen

Varianten

1. unstrukturiert:

lineare Bytefolgen (Linux, Windows, Mac OS X)

2. satz- oder baumstrukturiert, indexsequenziell (Mainframes)

4. Dateisysteme / 4.1 Dateimodelle / 4.1.2 Dateistrukturen


Unstrukturierte Dateien (= das Unix/Windows/-Modell)

Datei: Bytefolge

• keinerlei inhaltliche/strukturelle Interpretation durch Betriebssystem

elementares Model

hohe Flexibilität

performant realisierbar

manchmal: auch mühevoll, z.B.

o Speicherung strukturierter Daten wie Bankkonten

o Datenstrukturen aus Programmen etc.

Byte 0 1 2 3 . . .

w i r w e r d e n w i e ns s

Textdatei:

167 151 162 040 162 144 145 156 040 167 151 163 163 145 156

Was wirklich drin steht (UTF-8 Zeichencodierung, oktal („od –ba“))

167 145

Dateistrukturen



Strukturierte Dateien (Mainframe-Dateisysteme)

oft genutzte Standard-Strukturen

• satzstrukturiert, baumstrukturiert, indexsequenziell

• komfortabel, anwendungsnah

• Vorstufe der DBMS-Schemata

z.B. satzstrukturiert z.B. baumstrukturiert, mit Schlüsseln

wir müssen wissen wir werden KatzeHund Maus

Ibis Iltis

Igel

insert(Igel) →

Szene in Video ...

insert(Ibis,Iltis) →

Dateistrukturen



4.1.3 Dateiattribute

Sicherheitsattribute

Standard seit 50 Jahren:

wahlfreie Zugriffssteuerung (Discretionary Access Control [DAC])

1. Eigentümer, Gruppe

2. Zugriffssteuerungslisten: Listen mit Benutzern und Rechten

z.B. Unix: Eigentümer, Gruppe, Rest der Welt; jeweils rwx-Flags

z.B. NTFS, Mac OS EFS: Listen von Paaren (Name, Rechte)

(etwas) leistungsfähiger

jüngere, leistungsfähigere Dateisysteme (SELinux, TrustedBSD, SEAndroid):

obligatorische Zugriffssteuerung (Mandatory Access Control [MAC])

1. Klassifikationen

(z.B. „öffentlich/vertraulich/geheim“)

2. Sicherheitslabel

(z.B. Zugehörigkeit zu Organisationseinheit, örtliche Beschränkungen)

4. Dateisysteme / 4.1 Dateimodelle / 4.1.3 Dateiattribute


Beispiel: Zugriffssteuerungslisten in Unix

00010100100

10001010000

10111001101

01000100011

10001010000

10111001101

01000100011

00101001001

00010100100

10001010000

10111001101

01000100011

00101001001

Statistik

Nutzdaten Meta-Infos

Adr.-Info Eigentümer (z.B. „kuehnhauser“)

Gruppe (z.B. „alle

Lehrstuhlmitarbeiter“)

Rest der Welt

lesen, schreiben

lesen

-Zugriffs-steuerungsliste

Datei

Realisierung: 9 Bits ...

r w - r - - - - -Bits 15..9

rw- r-- --- 1 kuehnhauser CrewX 7 Dez 20:22 ProjectXFile

Dateiattribute



Weitere Attribute

1. Zugriffsstatistiken; Datum

• der Erstellung

• des letzten Lesezugriffs

• des letzten Schreibzugriffs

2. Nutzungszähler

Dateiattribute



4.1.4 Operationen auf Dateien

Benutzung von Dateien: Operationen der Betriebssystem-API (in Klammern die Namen der Unix-API)

Operationen (Systemaufrufe) Typische Parameter

1. Erzeugen (creat, open) Name, Attribute → Filedeskriptor (fd)

2. Löschen (unlink) Name

3. Öffnen (open) Name, Zugriffsart → fd

4. Schließen (close) fd

5. Inhalt lesen (read) fd, Anzahl Bytes (, Position) → Daten

6. Inhalt schreiben (write) fd, Anzahl Bytes (, Position), Daten

7. Positionszeiger setzen (lseek) fd, Position

8. in virtuellen AR einbinden fd, virtuelle Adresse

(mmap)

9. Attribute lesen (stat) Name → Attribute

10. Attribute setzen (chmod/own/grp) Name, Attribute

Syntax und Semantik: BS-spezifisch, definiert in API-Spezifikation

4. Dateisysteme / 4.1 Dateimodelle / 4.1.4 Operationen auf Dateien


Beispiel: Inhalt lesen

mit expliziter Filepointer-Positionierung

mit impliziter Filepointer-Positionierung

Byte 0 1 2 3 . . . 6 . . .

w i r w e r d e n w i e ns s

Textdatei Filepointer

char Puffer[10];

fd=open(“/Users/kuehnhauser/Desktop/hilbert“,…);

lseek(fd,1);

read(fd,2,Puffer); // Puffer enthält danach „ir“;

lseek(fd,6);

read(fd,3,Puffer); // Puffer enthält danach „rde“

char Puffer[10];

fd=open(“/Users/kuehnhauser/Desktop/hilbert“,…);

read(fd,2,Puffer); // Puffer enthält danach „wi“

read(fd,4,Puffer); // Puffer enthält danach „r we“;

read(fd,2,Puffer); // Puffer enthält danach „rd“



4.1.5 Zusammenfassung

Dateimodelle

unterscheiden sich durch

1. Namen und Namensräume

hierarchisch, Semantik

2. Dateistrukturen

un-, satz- oder baumstrukturiert

3. Attribute

Zugriffsschutz (Eigentümer, Zugriffsrechte, Klassifikationen)

Zugriffsstatistiken

4. Operationen

Semantik von Erzeugen, Löschen, Lese/Schreiboperationen

werden implementiert:

• durch Dateisysteme Anwendungsschnittstelle (Application Programmer‘s Interface, API)

OfficeGUI Google Earth

ABSMatLab Firefox

Betriebssystem-Dienste

Prozessmanagement Dateisysteme Netzwerkmanagement


Prozessor-

Ressourcen

Kommunikations-

Ressourcen

Speicher-

RessourcenE/A

Ressourcen



4.2 Dateisysteme

Problem

1. schnelles

2. effizientes

3. robustes

4. sicheres

Speichern und Wiederfinden von Dateien auf persistenten Speichermedien

≈ „Aktenschränke“

4. Dateisysteme / 4.2 Dateisysteme


Dateisystem Aktenschrank, bestehend aus

1. Metadaten: Datenstrukturen zum Management der Nutzdaten

2. Nutzdaten der Dateien

3. Algorithmen, die ein Dateisystem realisieren

Verbreitete „Aktenschrank“-Typen:1. FAT (File Allocation Table): QDOS, MS-DOS (1978)

2. NTFS (New Technology File System): Windows 2000/XP/Vista/7+

3. HFS+ (Mac OS Extended (journaled)): Mac OS, APFS: iOS

4. Ext∗ (Extended File System (∗=4: journaled)): Linux, IBM AIX

5. NFS (Network File System): Sun; Unix-Systeme, Windows-Systeme, ...

6. ISO 9660 für optische Speichermedien

Dateisysteme

4. Dateisysteme / 4.2 Dateisysteme


4.2.1 Speichermedien

Physisches Layout von Magnetplattenlaufwerken

1. Plattengeometrie: Sektoren, Spuren; mehrere Lagen: Oberflächen

2. Sektoren: elementare Zugriffseinheiten, z.B. 1024 Byte groß

Sektor eindeutig identifiziert durch 3D-Adresse:

(Sektornummer, Spurnummer, Oberflächennummer)

4. Dateisysteme / 4.2 Dateisysteme / 4.2.1 Speichermedien


Zugriffszeiten (Desktop/Server Laufwerke, 2017)

Rotationszeit 4-8 Millisekunden (10.000 min-1)

Armpositionierzeit 4-8 Millisekunden

(voller Schwenk, 200-400 Armpositionierungen/Sek)

Zugriffszeit auf Sektor

abhängig von Lage des Sektors in Relation zur aktuellen

Rotationsposition der Platte

Schwenkposition des Armes

• Größenordnung bei heutigen PC-typischen Laufwerken: 6-12 Millisekunden

→ kein wahlfreier Speicher !!

Datenrate 40-170 MByte/Sekunde

→ um Größenordnungen langsamer als Arbeitsspeicher !!

Speichermedien



SSDs vs. Magnetplatten (2017)

1. wahlfreier Zugriff (c.g.s.)

2. erheblich geringerer Stromverbrauch (technologieabhängig, 10%)

3. erheblich geringere Zugriffszeiten, 5%

4. erheblich höhere Datenraten, Faktor 3

5. erheblich teurer, Faktor 5-10

Speichermedien



4.2.2 Management-Datenstrukturen auf Speichermedien

Ziele

1. Speichern

2. Wiederfinden

von Dateien; schnell, effizient, robust, sicher

Management-Datenstrukturen (Metadatenstrukturen)

Datenstrukturen zur Organisation der Nutzdaten

1. Informationen über das Dateisystem selbst

2. Inhaltsverzeichnisse

3. Informationen über individuelle Dateien

4. Dateis. / 4.2 Dateis. / 4.2.2 Managem.-Datenstrukt. auf Speichermed.


4.2.2.1 i-Nodes(Information Nodes, Index Nodes)

Informationen über individuelle Dateien: i-Nodes

i-Node: Metainformationen über genau eine Datei (allg.: persistentes Objekt)

abhängig von konkretem Dateisystem:

1. enthaltene Informationen

2. Layout

3. Größe (≥ 128 Byte, teils >>)

Typischer i-Node

Nutzdaten-Adressen

(Sektorliste, Größe)

Zugriffsstatistik

Satzformat

Referenzzähler


Eigentümer, Gruppe

Objekttyp (Datei, Verzeichnis, …)

4. Dats. / 4.2 Dats. / 4.2.2 Managem.-Datenstrukt. / 4.2.2.1 i-Nodes


Nutzdaten-Adressen


Nutzdaten-Adressen


Man kann hineinsehen

wakatobi> ls –l

- rw- --- --- 1 Anna CrewX 12 Dez 20:22 ProjectXFiles

d rw- r-- --- 3 Anna CrewX 12 Dez 20:24 ProjectXBoard

- rw- r-- --- 1 Bernd Sales 12 Dez 20:24 SalesBoard

l rw- --- --- 1 Chris Sales 22 Dez 9:22 SX -> ProjectXFiles

Zugriffsstatistik

Satzformat

Referenzzähler


Eigentümer, Gruppe

Objekttyp (Datei, Verzeichnis, …)

i-Nodes


(umseitig)


Adressierung der Nutzdaten

.

.

.

Sektor 3456789

:

Sektor 7654321

Sektor 1234567

Nutzdatensektor

Nutzdatensektor

Nutzdatensektor

• • •

Nutzdaten-Beschreibung

im i-Node: Sektorliste

Nutzdatensektor

Sektoradressen

Nutzdatensektor

• • •

Sektor 87654

• • •

Nutzdatensektor

Nutzdatensektor

Sektoradressen

Sektoradressen

Sektoradressen

• • •

Sektor 765432

direkte

Adressierung

einfach indirekt

zweifach indirekt

logische i-Node-Erweiterungen (normale Plattensektoren)

i-Nodes



Wo stecken die i-Nodes? → Die i-Node-Tabelle

zentrale Meta-Datenstruktur eines (i-Node basierten) Dateisystems

• (logisch) genau eine je Dateisystem

• erzeugt bei Dateisystem-Erstellung (Unix „mkfs“, „Formatierung“)

• feste Länge

• i-Node-Nummer = Index in dieser Tabelle

(eindeutige Objekt-Id innerhalb eines Dateisystems)

i-Nodes



Nutzung von i-Nodes ...

... beim Lesen von Dateien

1. i-Node-Index der Datei besorgen (aus Verzeichnis, s.u.)

2. mit diesem Index: i-Node in der i-Node-Tabelle finden

3. aus dem i-Node lesen:

a) Schutzinformationen (Sicherheitsattribute)

b) Adressen der Nutzdaten

i-Nodes



... beim Erzeugen von Dateien

create(“/home/anna/ProjectXBoard“,)

1. Suche nach freiem i-Node in der i-Node-Tabelle

2. Dateiinfos in i-Node schreiben (z.B. Struktur, Schutzinformationen)

3. Name und i-Node-Index in Verzeichnis eintragen

... beim Schreiben von Daten

1. Adressierungsinformationen im i-Node aktualisieren

... bei der Freigabe von Dateien

1. Verzeichniseintrag löschen

2. falls letzter Verzeichniseintrag dieser Datei (↑Referenzzähler):

a) i-Node in i-Node-Tabelle als „frei“ markieren

b) Ressourcen (belegte Sektoren) freigeben

i-Nodes



4.2.2.2 Verzeichnisse

Aufgabe

Symbolische, hierarchische Namen ⟼ eindeutige Objekt-Id (=i-Node-Index)

Idee

1. Verzeichnis: Abbildung

symbolischer Namensraum → Objektnamensraum

Pfadnamenskomponente ⟼ Objekt-Id

2. alle Verzeichnisse gemeinsam: Abbildung

hierarchischer symbolischer Namensraum → Objektnamensraum

Pfadname ⟼ Objekt-Id

in Graph-Notation

• symbolischer Namensraum: baumähnlicher Graph

Knoten: Verzeichnisse

Kanten: attributiert mit Namen

• Pfadname: Folge von Kantennamen

4. Dats. / 4.2 Dats. / 4.2.2 Managem.-Datenstrukt. / 4.2.2.2 Verzeichnisse


Realisierung

Verzeichnis = Menge von Paaren (Name, i-Node-Index)

Beispiel

Ein typisches Linux-Wurzelverzeichnis:

wakatobi> ls -ia --format=single-column /2 .2 ..

131073 bin3 dev

786433 etc917505 home786435 lib

1 proc655363 tmpwakatobi>

Verzeichnisse



Beispiel: ein Linux-typischer Verzeichnis-BaumLogische Sicht

Wurzelverzeichnis „/“

home bin lib etc tmp

anna bernd chris

dok

Verzeichnis

„/home/chris“

(Knoten)

Dokument

„/home/chris/dok“

(Blatt)



Beispiel: ein Linux-typischer Verzeichnis-BaumDatenstrukturen

home

bin

lib

etc

tmp

anna

bernd

chris

dok

i-Node für

„dok“

i-Node Dokument

„/home/chris/dok“




Beispiel: ein Linux-typischer Verzeichnis-BaumPhysisch

Beispiel: Pfadnamenauflösung „/home

home

bin

lib

etc

tmp

i-Node-Nummer ●

i-Node-Nummer ●

i-Node-Nummer

i-Node-Nummer

i-Node-Nummer


/chris /dok“ homebin

lib

etc

tmp annaberndchris

dok

Nutzdatenadressen

anna

bernd

chris

i-Node-Nummer

i-Node-Nummer

i-Node-Nummer ●

dok i-Node-Nummer

Indizes in i-Node-Tabelle

i-Node-Tabelle

i-Node für bin

i-Node für home ■

i-Node für chris ■

Verzeichnis „/home“

Verzeichnis „/home/chris“



4.2.2.3 Die Freiliste

Management-Datenstruktur für freien Speicher

Sektoren sind

1. entweder in Benutzung; enthalten dann

a) Nutzdaten von Dateien oder Verzeichnissen

b) Metadaten, z.B. i-Nodes

2. oder frei

alle freien Plattensektoren: Freiliste

Organisation

• z.B. als Bitmap, je Plattensektor ein Bit (frei/belegt)

• z.B. als B-Baum (HFS)

effiziente Suche von Mustern

– zusammenhängende Bereiche

– benachbarte Bereiche

– Bereiche bestimmter Größe

0 0 0 0 0 0 0 1 1 0 0 1 1 0 0 1

4. Dats. / 4.2 Dats. / 4.2.2 Management-Datenstrukturen / 4.2.2.3 Freiliste


4.2.2.4 Der Superblock

Einstiegspunkt eines Dateisystems

erzeugt: bei Erstellung eines Dateisystems („mkfs“, „formatieren“)

steht: an wohldefiniertem Ort (direkt hinter (eventuellem) Boot-Sektor)

enthält: Schlüsselparameter

1. Name des Dateisystems

2. Typ (NTFS, Ext∗, HFS, ...) → Layout der Metadaten

3. Größe und Anzahl Sektoren

4. Ort und Größe der i-Node-Tabelle

5. Ort und Größe der Freiliste

6. i-Node-Nummer des Wurzelverzeichnisses

wird als erstes beim Öffnen („montieren“, s.u.) eines Dateisystems vom

Betriebssystem gelesen:

• Typ: passende Betriebssystem-Komponente

• i-Node-Liste, Freiliste: Metadaten zum Management

• Wurzelverzeichnis: logischer Einstiegspunkt

4. Dats. / 4.2 Dats. / 4.2.2 Managem.-Datenstruktur. / 4.2.2.4 Superblock


wakatobi> dumpe2fs –h /dev/sda1

Filesystem volume name: Linux Root

Last mounted on: /

Filesystem magic number: 0xEF53

Filesystem state: clean

Filesystem OS type: Linux

Inode count: 21766144

Block count: 87040162

Block size: 4096

Free inodes: 21541247

Filesystem created: Mon Oct 26 14:19:28 2015

First inode: 11

Inode size: 256

Journal inode: 8

Journal length: 128M

. . .

350 GB

16KB/Datei16KB/Datei

EXT4

Superblock

4. Dats. / 4.2 Dats. / 4.2.2 Managem.-Datenstruktur. / 4.2.2.4 Superblock


4.2.2.5 Zusammenfassung (4.2.2)

Superblock

i-Node für /bin

i-Node für /home

0 1 01 01 0 1 01 homebinetc

annaberndchris

.cshrc

doks

bilder

books

doks

videos

Metadatenstrukturen

1. Superblock

2. Verzeichnisse

3. i-Nodes und i-Node-Liste

4. Freiliste

4. Dats. / 4.2 Dats. / 4.2.2 Managem.-Datenstrukt. / 4.2.2.5 Zusammenf.


4.2.3 Datenstrukturen u. Algorithmen des Betriebssystems

Ablauf eines Dateizugriffs

1. Anwendungsprogramm:

2. im Folgenden: beteiligte

• Datenstrukturen

• Algorithmen

des Betriebssystems

fd=open(“/home/jim“, O_RDONLY);

switch (access-method) {

case per-Filesystem: read(fd, &buffer, nbytes);

case per-VMM: mmap(start, length, PROT_READ,

MAP_PRIVATE, fd, offset);

}

close(fd);

4. Dats. / 4.2 Dats. / 4.2.3 Datenstrukturen und Algorithmen des BS



Pfadnamenauflösung

1. Lesen des i-Nodes des Wurzelverzeichnisses (Superblock)

2. Lesen der Nutzdaten des Wurzelverzeichnisses: Suchen von „home“

3. Lesen des i-Nodes von „home“

4. Lesen der Nutzdaten des „home“-Verzeichnisses: Suchen von „jim“

5. Lesen des i-Nodes von „jim“: Prüfen der Rechte zum Lesen (O_RDONLY)

6. Anlegen eines Filedeskriptors im Prozess-Deskriptor,

Rückgabe von dessen Index (fd) an Aufrufer

home

bin

etc

lib

tmp

i-Node-Nummer •i-Node-Nummer •i-Node-Nummer •i-Node-Nummer •i-Node-Nummer •

Wurzelverzeichnis

i-Node für jim •

anna

bernd

i-Node-Nummer •i-Node-Nummer •i-Node-Nummer •

i-Node für /bin •i-Node für /home •

Prozessdeskriptor

User-Id

fd-Tabelle

(Rechte,

Filepointer)

Index

jim

„/home“-Verzeichnis

Superblock

Datenstrukturen und Algorithmen des Betriebssystems



read(fd, &buffer, nbytes);

Transfer von nbytes aus der geöffneten Datei fd zur Variablen buffer

1. Rechteprüfung

2. Zugriff auf Nutzdatenadressen im i-Node über fd-Tabelle im Prozessdeskriptor;

Ergebnis: Sektornummer(n) auf Speichermedium

3. Auftrag an Gerätetreiber: „Transfer der Sektoren in den BS-Cache“

4. Nach Fertigstellung (Interrupt):

Kopie des Caches nach buffer,

Rückgabe der Anzahl der tatsächlich gelesenen Bytes / Fehler

„buffer“

Medium BS-CacheAdressraum des

Anwendungsprozesses




... und im großen Kontext:

Anwendungssystem

Anwen-

dungs-

ebene

Betriebs-

system

BS-Dienste

Betriebssystem-Schnittstelle (Application Programmer‘s Interface (API))

Dateisystem

Speicher-

Ressourcen

Hardware Speicher

Anwendungssystem Anwendungssystem


KommunikationsmodelleProzessmgmnt . . .

Prozessor-

Ressourcen

Kommunikations-

Ressourcen

misc. E/A

Ressourcen


Kommunikation

(LAN, WLAN etc.)Prozessoren misc. E/A (Grafik,

Firewire, USB etc.)




... und im großen Kontext:

Anwendungssystem

Anwen-

dungs-

ebene

Betriebs-

system

BS-Dienste

Betriebssystem-Schnittstelle (Application Programmer‘s Interface (API))

HD-Gerätemanager

Hardware

DateisystemDateisystem

buffer




Alternative Zugriffsmethode: per VMM

mmap(start, length, PROT_READ, MAP_PRIVATE, fd, offset);

Einblenden einer Datei in (eigenen) Adressraum: vmp, Kap. 3

Zugriffsoperationen: sind reguläre Arbeitsspeicherzugriffe

Zugriff auf Medium: durch reguläre Seitenfehlerbehandlung des VMMs

(→ maparea auf Seitengrenze („page-aligned“))

Beispiel: Wirkung von read vs. mmap

void *maparea;

char buffer[220];


maparea=malloc(220);

mmap(&maparea, 220, PROT_READ, MAP_PRIVATE, fd, 0);

// per-Filesystem-Variante:

read(fd, &buffer, 220);// hiernach gilt i, 0i220-1:

// maparea[i]==buffer[i]




Gegenüberstellung read/write vs. mmap: Kontozugriff

struct konto_t konto;

off_t kontoOffset;

fd=open(“kontodatei“, O_RDWR);

kontoOffset = kontoNr*sizeof(konto_t);

lseek(fd,kontoOffset);

read(fd, &konto, sizeof(konto_t));

konto.stand = 0;

lseek(fd,kontoOffset);

write(fd, &konto, sizeof(konto_t));

struct konto_t kontenDB[kontenZahl];

fd=open(“kontodatei“, O_RDWR);

mmap(&kontenDB, ... , RW, ..., fd, 0);

kontenDB[kontoNr].stand = 0;

6 Operationen je Kontobewegung 1 Operation je Kontobewegung




read/write

Umständliche Benutzung

jede Operation erfordert Kopieren (teuer!)

Caching des Dateisystems wird genutzt

kleinste Transfereinheit 1 Sektor

mmap

1. direkter Zugriff auf Daten, implizite Leseoperationen per VMM

2. keine Kopieroperationen

3. VMM, working set, wird genutzt

4. kleinste Transfereinheit 1 Seite

„kontenDB“

„konto“




close(fd)

1. Freigabe des Filedeskriptors im Prozess-Deskriptor

2. Zurückschreiben der gecachten Informationen (i-Node, Nutzdaten)

a) implizit, im Rahmen des Dateisystem-internen Cachemanagements

(Alterung)

b) explizit, durch fsync()

munmap(start,length)

1. hebt Assoziation zwischen Datei und Arbeitsspeicher auf (vmp)

weitere Zugriffe: Speicherzugriffsfehler

2. Zurückschreiben modifizierter Seiten

a) implizit, im Rahmen des regulären Pagings (Verlassen des working sets)

b) explizit, durch msync()




4.3 Zusammenfassung (Kapitel 4)

Dateimodelle

bestimmen:

Syntax und Semantik von Dateinamen, -strukturen, -attributen, -operationen

Dateisysteme

Aktenschränke mit Dateien;

• Aufgabe: schnelles, effizientes, robustes, sicheres Speichern und

Wiederfinden von Dateien

Metadatenstrukturen auf Speichermedien

1. Superblock: der Einstiegspunkt

2. Verzeichnisse: implementieren hierarchische Namensräume

3. i-Nodes und i-Nodetabelle: Metadaten individueller Dateien

4. Freiliste, Journal

4. Datsysteme / 4.3 Zusammenfassung


Datenstrukturen des Betriebssystems

1. Filedeskriptortabelle im Prozessdeskriptor

→ offene Dateien (prozessindividuelle Rechte, Filepointer)

2. Caches in den Dateisystem-Implementierungen

• Nutzdatencache (buffer cache)

• Metadatencaches: i-Nodes, Verzeichniseinträge

Performanz

Zugriffsmethoden

1. per lesen/schreiben

2. per VMM

Zusammenfassung

4. Datsysteme / 4.3 Zusammenfassung
kap5.pptxkap5.pptx

Documents

H.-A. Schindler Kapitel 4: Dateisysteme · Schindler Folie: 1 -2 Roadmap Betriebs-system Anwendungsschnittstelle (Application Programmer‘s Interface, API) Anwen-dungs-ebene GUI