Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Speicher – Ergänzungen und Vertiefungen = == Blockspeicher vs. Dateispeicher == === Analogie === Stell dir den Hypervisor als '''Lagerverwalter''' vor.…“

2026-03-04T07:12:19Z

Die Seite wurde neu angelegt: „= Speicher – Ergänzungen und Vertiefungen = == Blockspeicher vs. Dateispeicher == === Analogie === Stell dir den Hypervisor als '''Lagerverwalter''' vor.…“

Neue Seite

= Speicher – Ergänzungen und Vertiefungen =

== Blockspeicher vs. Dateispeicher ==

=== Analogie ===

Stell dir den Hypervisor als '''Lagerverwalter''' vor.

Beim '''Blockspeicher''' (z.B. LVM, iSCSI, Ceph RBD) bekommt der Lagerverwalter einen leeren Bereich, der in nummerierte, gleich große Fächer aufgeteilt ist. Er kann dort VM-Festplatten als große zusammenhängende Blöcke ablegen — aber er kann nicht reinschauen, was drin ist. Er sieht nur "Block 47 bis 520 gehört zu VM-Disk disk-0 von VM 101". Was die VM intern damit macht (ext4 formatieren, Dateien anlegen), ist für den Hypervisor unsichtbar.

Beim '''Dateispeicher''' (z.B. Directory, NFS, CephFS) hat der Lagerverwalter ein fertiges Regalsystem mit Ordnern. Er sieht die VM-Disks als einzelne Dateien liegen — zum Beispiel <code>vm-101-disk-0.qcow2</code> im Ordner <code>images/101/</code>. Er kann die Datei kopieren, verschieben, umbenennen oder sichern, ohne die VM dafür fragen zu müssen. Genau deshalb eignet sich Dateispeicher gut für Backups und ISO-Images.

'''Kernunterschied aus Hypervisor-Sicht:''' Kann der Hypervisor die VM-Disks als Dateien sehen und anfassen, oder sind es nur Blockbereiche, die er als Ganzes verwaltet?

=== Dateisystem auf Blockspeicher? ===

Ein häufiges Missverständnis: Der Hypervisor legt bei echtem Blockspeicher '''kein''' Dateisystem drauf. Er nutzt stattdessen einen '''Volume Manager''' (LVM, Ceph RBD, ZFS Zvols), der die Zuordnung von Blöcken zu VMs übernimmt — das ist eine andere Abstraktionsschicht als ein Dateisystem.

* '''LVM/LVM-Thin:''' Verwaltet logische Volumes direkt als Blockgeräte. Die VM bekommt <code>/dev/dm-X</code> zugewiesen — ein rohes Blockgerät. Da liegt keine Datei <code>vm-101-disk-0.qcow2</code> in einem Ordner. Die Zuordnung läuft über LVM-Metadaten, nicht über ein Dateisystem.
* '''iSCSI:''' Der Hypervisor bekommt ein Blockgerät übers Netzwerk und reicht es direkt an die VM durch. Kein Dateisystem auf Hypervisor-Ebene.
* '''ZFS:''' Sonderfall, da ZFS beides gleichzeitig ist:
** '''ZFS Dataset''' → Dateispeicher, qcow2-Dateien liegen darin
** '''ZFS Zvol''' → Rohes Blockgerät, kein Dateisystem dazwischen

== Copy-on-Write (CoW) ==

=== Grundprinzip ===

Bei einem klassischen Dateisystem wie ext4 wird ein Block direkt überschrieben, wenn eine Datei geändert wird — der alte Inhalt ist danach weg. Bei ZFS passiert das nie:

# ZFS schreibt die neuen Daten in einen '''freien Block'''
# Der Zeiger im Metadaten-Baum wird aktualisiert
# Erst danach wird der alte Block als frei markiert

Der ursprüngliche Block wird also '''nie''' direkt überschrieben.

=== Konsistenz ohne Journal ===

Bei ext4 braucht man ein Journal, das Schreibvorgänge protokolliert, damit nach einem Stromausfall das Dateisystem repariert werden kann. ZFS braucht das nicht — weil der alte Zustand immer intakt bleibt, bis der neue vollständig geschrieben ist.

* Entweder der neue Zeiger wurde aktualisiert → neue Daten gelten
* Oder nicht → alte Daten gelten (intakt)

Es gibt keinen Zwischenzustand, in dem das Dateisystem inkonsistent sein könnte. Deshalb gibt es bei ZFS auch kein <code>fsck</code>.

=== Snapshots durch CoW ===

Wenn ZFS einen Snapshot erstellt, muss es '''keine Daten kopieren'''. Es merkt sich einfach: "Die Blöcke, die jetzt existieren, bitte nicht freigeben." Da CoW sowieso nie alte Blöcke überschreibt, bleiben die Snapshot-Blöcke erhalten, während neue Änderungen in neue Blöcke geschrieben werden.

* Ein Snapshot kostet initial '''null''' zusätzlichen Speicher
* Er wächst nur, wenn sich Daten ändern (alte Blöcke werden aufbewahrt statt freigegeben)

=== Metadaten-Baum (Merkle Tree) ===

ZFS organisiert alle Daten in einer Baumstruktur:

* Jeder Block hat eine Prüfsumme, die im '''übergeordneten''' Block gespeichert wird (nicht im Block selbst)
* Wenn sich ein Block ändert, muss CoW auch den Eltern-Block neu schreiben (Prüfsumme ändert sich), und dessen Eltern, bis hoch zum '''Überblock''' (uberblock) an der Wurzel
* Dadurch kann ZFS Korruption auf jeder Ebene erkennen

=== Auswirkungen in der Praxis ===

* '''Fragmentierung:''' Weil Blöcke nie an der gleichen Stelle überschrieben werden, fragmentiert der Speicher über die Zeit. Bei HDDs spürbar, bei SSDs weniger relevant.
* '''Schreib-Amplifikation:''' Durch das Neu-Schreiben des ganzen Pfads im Baum entsteht bei kleinen Änderungen mehr I/O als bei einem klassischen Dateisystem. Das ist der Preis für Konsistenz und Integrität.

=== Analogie für den Unterricht ===

Stell dir ein '''Notizbuch''' vor. Ein klassisches Dateisystem radiert eine Zeile aus und schreibt neu drüber — wenn dabei der Strom ausfällt, ist die Zeile halb radiert und unleserlich.

ZFS schreibt die neue Version auf eine '''frische Seite''' und ändert erst dann das Inhaltsverzeichnis. Fällt der Strom aus, steht im Inhaltsverzeichnis entweder noch die alte Seite (intakt) oder schon die neue (auch intakt).

Und ein Snapshot? Das ist einfach die Anweisung: "'''Diese Seite nicht rausreißen''', auch wenn wir eine neue Version haben."

== Disk-Formate: Raw vs. qcow2 ==

=== Raw ===

Ein 1:1-Abbild der virtuellen Festplatte. Wenn einer VM 50 GB zugewiesen werden, wird (bei Thick Provisioning) eine 50-GB-Datei oder ein 50-GB-Logical-Volume angelegt.

* Keine Struktur drumherum, keine Metadaten, kein Header — einfach nur rohe Blöcke
* Kommt bei Blockspeicher (LVM, Zvols, iSCSI) zum Einsatz, da Blockspeicher kein Dateiformat braucht
* '''Maximale Performance''' durch direkten Zugriff ohne Indirektion

=== qcow2 (QEMU Copy-on-Write, Version 2) ===

Ein intelligentes Container-Format mit Header, Metadaten und Zuordnungstabelle.

'''Vorteile gegenüber Raw:'''

* '''Thin Provisioning auf Dateiebene:''' Eine 50-GB-Disk belegt anfangs nur wenige MB und wächst mit den tatsächlich geschriebenen Daten
* '''Snapshots innerhalb der Datei:''' qcow2 kann intern mehrere Zustände halten. Bei einem Snapshot wird (ähnlich wie bei ZFS CoW) in einen neuen Bereich geschrieben, der alte bleibt erhalten
* '''Backing Files:''' Eine Basis-Datei (z.B. ein sauberes Debian-Image) kann als Grundlage dienen, davon abgeleitete qcow2-Disks speichern nur die Unterschiede (Linked Clones)

'''Nachteil:''' Kleiner Performance-Overhead durch die Zuordnungstabelle — jeder I/O muss erst aufgelöst werden.

=== Zusammenhang mit der Speicherart ===

{| class="wikitable"
|-
! Speicherart !! Format !! Thin Provisioning durch
|-
| LVM-Thin || Raw || LVM selbst
|-
| ZFS Zvol || Raw || ZFS selbst
|-
| iSCSI || Raw || Storage-Backend
|-
| Directory || qcow2 || qcow2-Format
|-
| NFS || qcow2 || qcow2-Format
|-
| ZFS Dataset || qcow2 || qcow2-Format
|}

Die Wahl des Disk-Formats hängt direkt mit der Speicherart zusammen: Bei Blockspeicher übernimmt der Volume Manager das Thin Provisioning, deshalb wird Raw genutzt. Bei Dateispeicher muss das Format selbst Thin Provisioning mitbringen, deshalb qcow2.

Proxmox Speicher - Versionsgeschichte

Maximilian.pottgiesser: Die Seite wurde neu angelegt: „= Speicher – Ergänzungen und Vertiefungen = == Blockspeicher vs. Dateispeicher == === Analogie === Stell dir den Hypervisor als '''Lagerverwalter''' vor.…“