20141202 Datei-Systeme II, virt. Speicher

20141202 Datei-Systeme II, virt. Speicher

Rechnerarchitekturen
und Betriebssysteme (CS201):
Dateisysteme II
Virtual Memory
2. Dezember 2014
Prof. Dr. Christian Tschudin
Departement Mathematik und Informatik, Universität Basel
Wiederholung / Diskussion
1. Was ist die Aufgabe eines Dateisystems?
2. Welche Ebenen unterscheidet man in einem Dateisystem?
3. Ist der Dateiname
– Teil einer Datei, oder
– Element eines Verzeichniseintrags?
4. Was ist der Unterschied zwischen einem symbolischen Link und
einem Hard-Link.
5. Warum möchte man für ein hierarchisches Dateisystem einen
azyklischen Graphen?
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 2/41
Sparse file = Datei “mit Löcher” (0-Bytes)
• Einfach abzubilden mit indexierter Allokation,
von den meisten UNIX Datei-Systemen unterstützt
(aber nicht ISO9600 CD-Format)
• Beispiele:
– core dumps
– noch nicht voll gefüllte Datenbank
• Wie solche Dateien erkennen? Demo für UNIX:
- vergleiche Angabe von ’ls’ und ’du -s’, oder
- selbe Angaben mit ’stat’ finden
• Siehe spezielle Optionen bei cp, oder tar
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 3/41
Sparse Datei (Prog um zu experimentieren)
#include <stdio.h>
int main()
/* Sparse file creation */
{
FILE *fp;
fp = fopen("sparse.dat", "w");
fseek(fp,131072-4,SEEK_CUR); /* 128 KB - 4 bytes */
fprintf(fp,"text");
fclose(fp);
return 0;
}
Nur letzter Block hat Inhalt (Rest ist 0). Demo: sparse-Option von cp,
auto|always|never, und du
(Geht nicht bei verschlüsselten Dateisystemen).
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 4/41
File Descriptor Table
Kernel muss Uebersicht behalten über alle offenen Dateien
(Cache, Pufferverwaltung)
• System-weite “open-file table”
– führt alle momentan offenen Dateien, siehe auch lsof
– cached die Abbildung von Datei auf inode
• Per-Prozess “Open-file table”
prozess-spezifische Daten wie
– Zugrifssmodus (r/w)
– aktuelle Lese/Schreibe-Position in der Datei
“File handle”, “descriptor”: Integer-Wert als Index in diese Tabelle
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 5/41
Uebersicht: vom File-Descriptor zum Inode
data
blocks
.
.
.
read (4, ...)
sync
tables of
open files
(per process)
user space
c Christian Tschudin
file-structure
table
system space
in-core
inode
list
inode
list
disk space
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 6/41
Dateisystem: Mount
Bisher gesehen: 1 Harddisk-Partition mit 1 Dateisystem
• Ueblicherweise: mehrere Teil-Dateisysteme. Z.B.:
– weitere HD-Partitionen
– Dateisystem im Netzwerk
• mount:
Dateisystem in den lokalen Adressraum einklinken
Windows: von CP/M geerbter expliziter Verweis auf Device (C:, D:)
UNIX: 1 Baum
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 7/41
Dateisystem: Mount (Forts)
/
/
/mnt
/priv
/usr
/data
/mnt/cd
/usr/bin
CD
Harddisk
Ein Dateisystem wird in ein anderes eingehängt:
Zugriff auf Datei → /mnt/cd/priv/datei.name
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 8/41
Dateisystem: Virtual File System
Betriebssystem muss mehrere Dateisystem-Typen unterstützen
• Virtual File System: Schicht zwischen logischem
Dateisystem und den darunterliegenden (spezifischen)
Ebenen (Speicherblock- und Device-Ebenen)
• NTFS
FATxx
ext2, ext3
iso9660
SMB
http (!)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 9/41
Dateisystem: Virtual File System (Forts)
root
swap
logical file system
c Christian Tschudin
file systems
logical devices
physical devices
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 10/41
Dateisystem: Loop File System, Stackable FS
Spezielles “Device”: loop
• Loop device: Datenblöcke werden nicht von einem
Device geliefert, sondern von einem Softwaremodul
• Loop-Device-SW kann eigene Speicherblöcke verwalten:
– von einer Datei lesen (!)
– Kompression
– Verschlüsselung
Beispiel: Dateisystem in einer Datei
# mount -o loop test.ext3 /mnt/tmp
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 11/41
Dateisystem: RAID
RAID = Redundant Arrays of Independent/Inexpensive Disks
• Diskblöcke mehrfach ablegen, um bei Disk-Crash Daten
restaurieren zu können
• Stripping:
Daten verteilen, z.B. 1 Disk für jede Bit-Position, 8 Disks
• RAID level 0: keine Redundanz
RAID level 1: Disk Mirroring
RAID level 2: Parity based error correction
. . . level 6: kann bis zu zwei HD-Ausfälle verkraften
• “Hot spare”: defekte Disk wird automatisch ersetzt
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 12/41
Dateisystem: /proc
Dateisystem als Organisationskonzept von UNIX, /proc in Linux
Hier: Namensraum verwenden, auch wenn keine eigentliche Dateien
• Alle Kernel-Daten:
/proc/cpuinfo
/proc/devices
/proc/..processnr..
‘‘Steckbrief’’ der Maschine
Liste
Verzeichnis für jeden Prozess
• Einträge können z.B. mit cat gelesen
oder mit echo beschrieben werden
• Windows: siehe Registry
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 13/41
Dateisystem: Named Pipes
• Pipes gehören nicht zu Dateisystemen:
Pipes = interner (zeichenbasierter) Kommunikationskanal
• Betriebssystem-Aufruf:
{
int fd[2];
pipe(fd); // erzeugt pipe inode: fd[0] lesen, fd[1] schreiben
...
erzeugt “anonyme Pipe”. z.B. auch bei ls | wc
• Pipe mit Name (FIFO):
% mkfifo /tmp/thepipename
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 14/41
Dateisystem: File Locks
Betriebssystem kann Dateizugriff schützen: file “locks”
• Dateien als “shared resource”:
gleichzeitiger Zugriff von mehreren Programmen
• Zugriff schützen/kontrollieren:
einen “Lock” anmelden kann den Prozess blockieren
• Vielzahl von “Locks”, z.B. SUN Solaris 2:
kann sogar Datei-Regionen “locken”
• Siehe z.B. man 3 lockf (Posix file lock)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 15/41
Dateisystem: Ausblick
Es wäre noch viel zu sagen:
• read-only (CD: ISO-9660), write-once FS
• verteilte Dateisysteme: Andrew, NFS, Storage Area Network, . . .
• Google-FS, Amazon S3, Hadoop für “Big Data”
• Indexierung (Google Desktop), Datenbank im OS (Longhorn)
• Integration mit Applikation (eMail-Attachments nicht mehr mehrfach ablegen),
Deduplifikation
• Verschlüsselte Dateisysteme, integriertes Backup,
Versionierung, peer-to-peer, freenet, etc etc
In Zukunft sind bei FS weiterhin Neuentwicklungen zu erwarten.
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 16/41
Neues Kapitel: (Haupt-)Speicherverwaltung
Idealisiertes Memory Layout für Unix (Bsp Linux)
1
0
0
1
0
1
000000000000
111111111111
0
1
000000000000
111111111111
0
1
0
1
000000000000
111111111111
0
1
0
1
000000000000
111111111111
0
1
111111111111
000000000000
000000000000
111111111111
000000000000
111111111111
000000000000
111111111111
0
1
000000000000
111111111111
0
1
000000000000
111111111111
0
1
Kernel Virtual Memory
Memory invisible to user mode code
Stack
Memory-mapped region
Memory-mapped region
Memory-mapped region
the ‘brk’ pointer
Run-time data
Uninitialised data
Initialised data
111111111111
000000000000
000000000000
111111111111
000000000000
111111111111
Program text
• Linux: linearer
Adressraum
• Regionen:
code (text)
initial. var (data)
uninit. var (bss)
• Heap
Libraries
Stack
Kernel
Forbidden region
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 17/41
Hauptspeicherverwaltung: Problemstellung
• Physikalischer Speicher begrenzt, oft zu klein
• Logischer (Speicher-) Adressraum abbilden auf
physikalischen Speicher
• Wann wird einer Speicheradresse die Speicherzelle zugewiesen?
– Kompilation, Linking
– Laden des Programms
– Ausführen des Programmes
Virtueller Speicher: “Binding” erfolgt zur Laufzeit,
muss von der Hardware (bei jedem Zugriff) übersetzt werden.
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 18/41
Repetition: Swapping
Swapping = Disk-Auslagerung eines (ganzen) Prozesses
Swapping = Unix: Swap-Partition, Windows: swap-Datei
operating
system
1
2
swap out
swap in
user
space
process
P1
process
P2
backing store
main memory
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 19/41
Virtueller Speicher
Virtueller Speicher = Separierung des logischen Speichers von den
physikalischen Speichermöglichkeiten (RAM, Harddisk)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 20/41
Virtueller Speicher (Forts.)
Prozesse ausführen, die grösser sind als der Hauptspeicher.
• Prozess-Memory-Teile können sich befinden:
– im physikalischen Hauptspeicher
– auf Harddisk (swap space)
• Transfer zwischen Harddisk und Hauptspeicher:
Swapping vs (Demand) Paging
– welches Programm/”Page” ist im Haupt-/Sekundärspeicher?
– wann welches Programm/Page transferieren?
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 21/41
Memory Management: Paging
In einem Multiprogrammiersystem:
• Mehrere Programme gleichzeitig im Speicher,
nach Ausführung eines Programms entstehen nichtzusammenhängende Zonen mit freiem Speicher:
wie zusammenführen?
• Physikalischer Speicher in “Frames” einteilen,
logischer Speicher in “Pages” (Grösse: 0.5 bis 4 KB)
• Logischer Page-Bereich abbilden auf physikalische Frames
→ Adressübersetzung
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 22/41
Paging (Forts)
Paging = Memory Mgmt für nicht-zusammenhängenden Speicher
logical
address
CPU
p
physical
address
d
f
d
physical
memory
• Abbildung von Pages
(Speicher-“Seiten”)
auf Frames (Speicher“Rahmen”):
Page Table
• Adressübersetzung
durch Hardware:
memory management
unit (MMU)
p
f
page table
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 23/41
Memory Management: Page Table (Beispiel)
frame
number
page 0
page 1
page 2
page 3
logical
memory
0
0
1
1
4
2
3
3
7
page table
1
page 0
2
3
page 2
4
page 1
5
6
7
page 3
physical
memory
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 24/41
Memory Management: Page Table Implementierung
• Page Table selbst benötigt 1 “Frame”, bleibt im Hauptspeicher
• Wird von MMU (memory management unit) bei jedem (!)
Speicherzugriff ausgelesen
• Inhalte eines Page Table-Eintrages:
– Attribute (abgebildet oder nicht, read-only, swapped) –
Frame-Nummer (oder Block-Nummer falls ausgelagert)
• Nun zweifacher Speicherzugriff!
– Cache nötig: TLB (translation look-aside buffer)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 25/41
Valid/Accessed/Dirty –Bits
Page Table für die “Buchhaltung”
• Bisher in der Page Table: Frame-Nummer
• Zusätzliche Attribute:
– present-Bit (d.h. im Hauptspeicher, gemapped)
– sonst: invalid, oder auf Harddisk
#define
#define
#define
#define
#define
#define
#define
_PAGE_PRESENT
_PAGE_RW
_PAGE_USER
_PAGE_PWT
_PAGE_PCD
_PAGE_ACCESSED
_PAGE_DIRTY
c Christian Tschudin
0x001
0x002
0x004
0x008
0x010
0x020
0x040
#define
#define
#define
#define
#define
#define
_PAGE_PSE
_PAGE_GLOBAL
_PAGE_UNUSED1
_PAGE_UNUSED2
_PAGE_UNUSED3
_PAGE_FILE
0x080
0x100
0x200
0x400
0x800
0x040
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 26/41
Memory Management: mehrstufige Pagetables
• Bei grossem virtuellen Speicher werden die Page-Tables zu
gross:
– 2 GB mit 4 KB-Pages: 0.5 M Einträge
– jeder Prozess braucht seine Tabelle
• deshalb mehrstufige Page Tables,
erlaubt “Löcher” analog “sparse files”
(siehe nächstes Slide)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 27/41
Memory Management: mehrstufige Pagetables
0
1
1
..
.
100
..
.
500
..
.
100
..
.
..
.
..
.
500
..
.
708
..
.
outer-page
table
929
..
.
708
900
..
.
900
page of
page table
page table
..
.
929
..
.
memory
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 28/41
Memory Management: mehrstufige Pagetables (Forts)
Beispiel:
• 4K Pages, 32-Bit-Architektur (32-Bit-Adressen)
• Aufteilung
– Page-Nummer: 20 Bits
– Page Offset: 12 Bits
• Page-Nummer in zwei Teile à je 10 Bits: addr (32 bits) =
p1 (10 bits) | p2 (10 bits) | offs (12 bits)
• p1: Index in äusserer Page Table,
p2: Index innerhalb der durch p1 referenzierten Page
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 29/41
Memory Management: Tricks mit Page Tables
• Shared Pages (shared code, shared memory):
– nur einmal im physikalischen Speicher vorhanden
– mehrfach in Adressraum von Prozessen “eingeblendet”
• Memory Protection:
– jeder Prozess hat sein eigener virtueller Speicher
– Zugriff ausserhalb der allozierten Zonen: Programmabbruch
• Dynamische Zuteilung:
– Stack und Heap: brk-Limite
• Swapping:
– einzelne Seiten auf Harddisk auslagern, Info in Page-Table
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 30/41
Memory Management: Segmente / Pages
• Segment-Konzept:
– unterschiedliche Zonen (Code, Daten), deshalb “Segmente”
– Adresse = “segment-descriptor” + Offset
• CPU führt Buch über mehrere Segment: segment table
– (physikalischer) Ort des Stack-Segments, Code, OS etc
– implizite Referenzierung: Stack-Segment, Code-Segment
• Intel x86-Architektur:
– ab x286: segments
– ab x386: paged segments
• Linux: linearer Adressraum (nur 1 Segment)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 31/41
Page Fault
Virtueller Speicher grösser als physikalischer Speicher
• Hardware (MMU) erkennt Zugriff auf “nicht gemappte” Seiten
• page fault trap
• Betriebssystem kann Grund untersuchen:
– ungültiger Adressbereich (Zone) ?
Dies kann aufwendig sein (viele Zonen)
• Sonst “demand paging”: Seite wird vom Harddisk geholt
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 32/41
Ablauf bei Page Fault
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 33/41
Page Fault-Handling: Schwierigkeiten
“Restart” des Befehls nötig
• Einfachster Fall: Page fault wegen Operand
– zuerst Page holen, dann Instruktion ausführen
• Schwieriger: Page fault wegen Resultat
– Operation muss nochmals ausgeführt werden
– Probleme mit Seiteneffekte (z.B. Y++)
• Noch grössere Seiteneffekte denkbar:
– Kopier-Operationen ganzer Speicherbereiche
(z.B. teilweises Kopieren rückgängig machen?)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 34/41
Paged Kernel-Speicher ?
Können Teile des OS auch “ge-paged” werden?
• ja!
• Für Daten (z.B. Daten-Puffer)
• Prinzipiell auch für Code möglich,
Performance . . .
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 35/41
Copy-On-Write (COW)
Prozess-Start unter UNIX fork():
• Erzeugt neben dem Eltern- ein Kind-Prozess
• Dabei wird nur die Speicher-Map kopiert, nicht der Inhalt:
– Page Tables beider Prozesse zeigen auf selben Speicher
• Zusätzlich:
– das RW-Flag wird weggenommen (d.h. readonly page)
• Beim nächsten Page-Fault:
– dem Kind-Prozess eine eigene Kopie anfertigen
– beim Eltern-Prozess das RW-Flag wieder setzen
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 36/41
On-Demand Paging
Seiten werden nur geladen, wenn sie benötigt werden.
• Prozess starten:
– Speicher-Map initialisieren
– Data-Bereich füllen
– nur erste (Code-) Seite laden
– Kontrolle an Prozess übergeben
• Weitere (Code-) Seiten werden “bedarfsweise”
(on demand) geholt
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 37/41
Zitat am Anfang der Veranstaltung vorgestellt
The Linux memory manager implements demand paging with a copy-on-write strategy relying on the 386’s
paging support. A process acquires its page tables
from its parent (during a fork()) with the entries marked
as read-only or swapped. Then, if the process tries to
write to that memory space, and the page is a copyon-write page, it is copied, and the page is marked
read-write. An exec() results in the reading in of a page or so from the executable. The process then faults
in any other pages it needs.
Linux Kernel Hacker’s Guide 0.5
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 38/41
On Demand Paging – Seiten-Ersetzung
Multi-Programming: Wettstreit um freie Frames
• Falls mehrere Programme aktiv sind:
– wer bekommt wieviele Frames?
– welche Pages werden auf HD ausgelagert?
• Aktivität und Alter eine Seite:
– welche Seiten wurden angetastet (ACCESSED Bit) ?
– “least recently used” (LRU)-Seite bestimmen
• Verschiedene Algorithmen, um sich LRU anzunähern
(volles LRU wäre zu aufwendig)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 39/41
Thrashing
• Pageing funktioniert wegen der Lokalität
– ein Prozess arbeitet meistens mit wenigen Seiten
– diese Seiten verschieben sich langsam
• Falls ein Prozess zuwenig Seiten im Hauptspeicher hat:
hohe page-fault Rate → niedrige CPU-Nutzung
• Trashing:
ein Prozess ist mit Paging (in und out) beschäftigt,
tangiert auch andere Prozesse (weniger CPU und IO-Bandbreite)
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 40/41
Thrashing (Fortsetz.)
CPU utilization
thrashing
degree of multiprogramming
Dieses Verhalten kann durch simples Programm provoziert werden:
– definiere grosses Array (> physikalischer Hauptspeicher)
– randomisierter Zugriff auf einzelne Elemente des Arrays
c Christian Tschudin
CS201 – Rechnerarchitekturen und Betriebssysteme, 2014-12-02, 41/41