ZFS auf VPS: Wie viel RAM braucht der ARC?

Was ZFS bietet und welche Ressourcen es benötigt

ZFS verwendet auf FreeBSD und Linux inzwischen dieselbe Codebasis, OpenZFS. Daher sind die Funktionen auf beiden Systemen identisch. Ein Server mit ZFS erhält Daten mit Prüfsummen, Snapshots, die bis zu einer Datenänderung keinen zusätzlichen Speicherplatz belegen, Replikation mit zfs send und Komprimierung, die sich mit einer einzigen Eigenschaft aktivieren lässt. Dafür benötigt ZFS Arbeitsspeicher: Der ARC (Adaptive Replacement Cache) belegt standardmäßig einen großen Teil des RAM. Auf einem VPS (Virtual Private Server) mit 2 GB oder 4 GB ist das genau der Arbeitsspeicher, den Ihre Anwendung benötigt.

Dieser Leitfaden bewertet ZFS auf einem gemieteten VPS mit einer oder zwei virtuellen Festplatten, nicht auf einem Speichersystem mit vierzig Laufwerksschächten. Die Funktionen, die unter diesen Bedingungen erhalten bleiben, sind den Aufwand wert. Die Einschränkungen, die sich unter diesen Bedingungen zeigen, sollten Sie kennen, bevor Sie einen Pool erstellen.

OpenZFS auf FreeBSD und Linux: eine Codebasis, zwei Paketierungsmodelle

FreeBSD führt ZFS seit FreeBSD 7.0 im Jahr 2008 im Basissystem, zunächst als experimentelle Funktion. Seit OpenZFS 2.0 im Dezember 2020 bauen FreeBSD und Linux aus demselben Quellbaum. Dadurch verhalten sich zfs und zpool auf beiden Systemen gleich, und ein auf dem einen System erstellter Pool kann auf dem anderen importiert werden.

Der Grund dafür, dass ZFS unter Linux ein Paket und unter FreeBSD Bestandteil des Basissystems ist, liegt in der Lizenzierung. OpenZFS steht unter der CDDL (Common Development and Distribution License). Der Linux-Kernel steht unter der GPL (General Public License) Version 2. Das Kernel-Projekt betrachtet beide Lizenzen als inkompatibel. Deshalb wird der ZFS-Code nicht in den Mainline-Linux-Kernel übernommen, und jede Distribution entscheidet selbst, wie sie ihn bereitstellt. FreeBSD hat diesen Konflikt nicht. Dort ist ZFS einfach vorhanden. Das ist die gesamte praktische Erklärung: ein Unterschied bei der Paketierung, bei dem Sie keine Position beziehen müssen.

SSD Nodes bietet keine FreeBSD-Images an. Auf einem hier gemieteten Server gilt daher der Linux-Teil dieser Anleitung. Wenn Sie FreeBSD an einem anderen Ort betreiben, erhält ein FreeBSD-Server ZFS, ohne dass Sie ein Modul bauen oder ein Kernel-Upgrade überstehen müssen.

ZFS installieren und einen Pool erstellen

Unter Ubuntu ist das Modul in den Kernel-Paketen enthalten. Sie müssen daher nur die Befehle installieren.

sudo apt update
sudo apt install -y zfsutils-linux
zfs version

zfs version gibt zwei Zeilen aus: die Userland-Version und die Version des Kernel-Moduls. Nur eine Zeile bedeutet, dass das Modul nicht geladen wurde. Das Paket befindet sich in der Komponente universe. Diese ist in Ubuntu-Server-Images standardmäßig aktiviert. Wenn apt das Paket nicht findet, führen Sie zuerst sudo add-apt-repository universe aus.

Unter Debian befinden sich die Pakete in der Komponente contrib. Das Modul wird von DKMS (dynamic kernel module support) auf Ihrem System erstellt. Fügen Sie contrib zur Components:-Zeile in /etc/apt/sources.list.d/debian.sources hinzu und führen Sie sudo apt update aus. Anschließend:

sudo apt install -y linux-headers-$(dpkg --print-architecture) zfs-dkms zfsutils-linux

Bei der Installation wird das Modul kompiliert. Dabei wird Building initial module for 6.12.0-... ausgegeben, was einige Minuten dauern kann. Beachten Sie die Konsequenz: Bei jedem Kernel-Upgrade wird das Modul neu erstellt. Wenn der Build fehlschlägt, bleibt Ihr Pool importiert, bis Sie das Problem beheben.

Unter FreeBSD ist nichts installiert. Aktivieren Sie den Dienst und starten Sie ihn.

sysrc zfs_enable=YES
service zfs start

Jetzt erstellen Sie den Pool. Prüfen Sie zuerst die stabilen Gerätepfade. /dev/vdb wird in der Erkennungsreihenfolge vergeben und kann sich ändern, wenn Sie ein weiteres Volume anschließen.

ls -l /dev/disk/by-id/
sudo zpool create -o ashift=12 tank /dev/disk/by-id/virtio-abc123def456
zpool status tank

zpool status sollte state: ONLINE ausgeben. Dabei muss Ihr Gerät unter tank aufgeführt sein. ashift=12 legt die kleinste Blockgröße des Pools auf 4 KiB fest. Das entspricht aktuellen SSDs und kann nach der Erstellung nicht geändert werden.

Die meisten gemieteten Images starten von einem ext4-Root-Dateisystem. ZFS wird hier daher als Datenpool auf einem zweiten Volume verwendet und nicht als Root-Dateisystem. Prüfen Sie vor der Erstellung, ob es sich bei dem Gerät tatsächlich um das erwartete Gerät handelt. Bestätigen, dass es sich um die bereitgestellte NVMe-Festplatte handelt dauert eine Minute. Eine Neuerstellung dauert dagegen einen Nachmittag.

Prüfsummen können nur reparieren, wenn der Pool Redundanz hat

Jeder von ZFS geschriebene Block erhält eine Prüfsumme, und bei jedem Lesen wird sie überprüft. Die Erkennung funktioniert immer. Für eine Reparatur wird eine zweite Kopie benötigt.

Bei einem Pool mit nur einem Datenträger teilt ZFS Ihnen die Wahrheit mit und beendet den Vorgang dort. zpool status -v meldet das so:

status: One or more devices has experienced an error resulting in data
        corruption.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
errors: Permanent errors have been detected in the following files:

        /tank/data/archive.tar

Die fehlerhafte Datei wird genannt. ext4 hätte diese Bytes kommentarlos zurückgegeben. Schon deshalb ist diese Information wertvoll. ZFS kann den Fehler trotzdem nicht beheben, weil im Pool keine zweite Kopie vorhanden ist, aus der der Block wiederhergestellt werden kann.

Bei einem Mirror wird derselbe Lesevorgang von der fehlerfreien Seite bedient. Der fehlerhafte Block wird neu geschrieben, und das Ereignis erscheint in der Spalte CKSUM von zpool status. Das ist Selbstheilung. Dafür werden zwei Geräte benötigt.

sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/DISK1 /dev/disk/by-id/DISK2

Auf einem VPS ist der Host-Speicher normalerweise bereits redundant ausgelegt, häufig als RAID 10 unter dem Hypervisor. Das schützt Sie vor dem Ausfall eines Laufwerks. Es erkennt jedoch nicht, wenn ein Block fehlerhaft zurückgegeben wurde, weil das Array nicht feststellen kann, welche Kopie korrekt ist. ZFS kann das erkennen, weil es die Daten mit einer von ZFS selbst geschriebenen Prüfsumme vergleicht.

Wenn Sie nur eine virtuelle Festplatte haben und dennoch eine gewisse Reparaturfähigkeit benötigen, speichert sudo zfs set copies=2 tank/important zwei Kopien jedes Blocks dieses Datasets auf derselben Festplatte. Dadurch verdoppelt sich der von diesem Dataset belegte Speicherplatz. Ein fehlerhafter Block kann damit überstanden werden. Wenn das gesamte Volume verschwindet, hilft diese Einstellung nicht.

Ein Scrub liest alle Daten im Pool und überprüft sie.

sudo zpool scrub tank
zpool status tank

Ein fehlerfreier Pool endet mit einer Zeile wie scan: scrub repaired 0B in 00:04:11 with 0 errors. Planen Sie den Vorgang regelmäßig ein. Für einen kleinen Pool ist ein monatlicher Lauf ausreichend.

systemctl list-unit-files 'zfs-scrub*'
sudo systemctl enable --now zfs-scrub-monthly@tank.timer

Datasets sind die Einheit für Richtlinien

Ein Dataset ist ein Dateisystem innerhalb des Pools. Da das Anlegen kaum Aufwand verursacht, sollten Sie für jeden Zweck ein eigenes Dataset erstellen. Eigenschaften werden vom Pool an untergeordnete Datasets vererbt. Dadurch legen Sie einen Standard einmal fest und überschreiben ihn nur dort, wo es erforderlich ist.

sudo zfs create tank/data
sudo zfs create tank/pg
sudo zfs set compression=lz4 tank
sudo zfs set atime=off tank
sudo zfs set quota=20G tank/data
sudo zfs set recordsize=16K tank/pg
zfs get -r compression,compressratio,quota tank

Die Komprimierung wird aus Vorsicht häufig deaktiviert. Das ist nicht sinnvoll. lz4 benötigt wenig CPU und reduziert die Datenmenge, die auf die Festplatte geschrieben werden muss. Bei komprimierbaren Daten werden Lese- und Schreibvorgänge dadurch meist schneller. zstd komprimiert stärker und benötigt dafür mehr CPU. Das eignet sich für Logs und Archive, auf die Sie selten zugreifen. Prüfen Sie mit zfs get compressratio tank, welche Komprimierung tatsächlich erreicht wird. Das Verhältnis berücksichtigt nur Daten, die nach dem Setzen der Eigenschaft geschrieben wurden.

recordsize bezeichnet die maximale Blockgröße, die ein Dataset schreibt. Der Standardwert ist 128K. Eine Datenbank, die 8 KiB große Seiten in 128 KiB große Datensätze schreibt, macht aus einem kleinen Schreibvorgang einen Lesevorgang des gesamten Datensatzes, eine Änderung und einen erneuten Schreibvorgang. Setzen Sie recordsize=16K auf dem Datenbank-Dataset, bevor Sie die Daten laden. Die Eigenschaft gilt nur für neu geschriebene Blöcke.

quota verhindert, dass ein einzelnes Dataset den gesamten Pool füllt. Ein ZFS-Pool, der fast 100% belegt ist, wird langsam und lässt sich nur schwer bereinigen. Lassen Sie daher bewusst freien Speicher als Reserve.

Snapshots belegen keinen Speicherplatz, bis sich Daten ändern

ZFS überschreibt niemals einen aktiven Block. Es schreibt einen neuen Block und aktualisiert die Zeiger. Das bezeichnet man als Copy-on-Write. Ein Snapshot enthält die Information, dass die Blöcke, auf die dieses Dataset aktuell zeigt, erhalten bleiben sollen. Deshalb wird ein Snapshot sofort und ohne zusätzlichen Speicherplatz angelegt.

sudo zfs snapshot tank/data@2026-08-11
zfs list -t snapshot -o name,used,refer -r tank/data

Die Spalte USED eines Snapshots zeigt den Speicherplatz, der ausschließlich von diesem Snapshot belegt wird. Zu Beginn ist der Wert nahezu null. Er steigt, wenn Sie Daten ändern oder löschen, weil die alten Blöcke dann nicht mehr freigegeben werden können.

Eine Datei lässt sich ohne Wiederherstellungsschritt zurückholen.

ls /tank/data/.zfs/snapshot/
cp /tank/data/.zfs/snapshot/2026-08-11/notes.txt /tank/data/notes.txt

Das Verzeichnis .zfs ist auch für ls -a verborgen, bis Sie sudo zfs set snapdir=visible tank/data ausführen. Erstellen Sie den Snapshot, bevor Sie ihn benötigen. Ohne Snapshot führt ein versehentliches rm -rf Sie in den ext4-Wiederherstellungspfad. Dieser beginnt mit dem Aushängen des Datenträgers und wird danach noch aufwendiger.

Ein Rollback verwirft alle Änderungen, die seit dem Snapshot geschrieben wurden.

sudo zfs rollback tank/data@2026-08-11

Der Vorgang wird verweigert, wenn neuere Snapshots vorhanden sind. Mit -r werden diese neueren Snapshots gelöscht, damit der Vorgang fortgesetzt werden kann. Lesen Sie den Dataset-Namen zweimal, bevor Sie die Eingabetaste drücken.

Ein Snapshot ist kein Backup. Er befindet sich im selben Pool, auf demselben Volume und auf demselben Server. Ein ausgefallenes Volume oder ein zpool destroy nimmt die Snapshots zusammen mit den Daten mit. Snapshots schützen Sie vor eigenen rm und vor einem fehlerhaften Upgrade. Damit decken sie viele reale Vorfälle ab. Sie schützen Sie jedoch nicht vor Ereignissen, die den Pool selbst betreffen. Die vollständige Erläuterung finden Sie hier: warum ein VPS-Snapshot kein Backup ist.

Senden und Empfangen: Replikation mit einem Befehl

zfs send wandelt einen Snapshot in einen Byte-Stream auf der Standardausgabe um, und zfs receive wandelt diesen Stream wieder in ein Dataset um. Die erste Kopie ist eine vollständige Übertragung.

sudo zfs snapshot tank/data@daily-2026-08-11
sudo zfs send tank/data@daily-2026-08-11 | ssh backup.example.com "sudo zfs recv -F backup/data"

Übertragen Sie danach nur die Änderungen zwischen zwei Snapshots.

sudo zfs snapshot tank/data@daily-2026-08-12
sudo zfs send -i tank/data@daily-2026-08-11 tank/data@daily-2026-08-12 | ssh backup.example.com "sudo zfs recv backup/data"

Auf der Empfängerseite muss der Snapshot, von dem Sie senden, weiterhin vorhanden sein. Ist das nicht der Fall, wird der Empfang mit cannot receive incremental stream: most recent snapshot of backup/data does not match incremental source beendet, weil ZFS keine Basis hat, auf die es die Änderungen anwenden kann. Senden Sie von einem Snapshot, der auf beiden Seiten vorhanden ist, oder beginnen Sie erneut mit einer vollständigen Übertragung.

Vergeben Sie die Rechte auf dem Zielsystem, statt remote root zu verwenden: sudo zfs allow -u backupuser create,mount,receive backup/data.

Das ist ein echtes Offsite-Backup, allerdings unter einer Bedingung. Das entfernte Ziel muss ein ZFS-Pool sein, da Object Storage keinen Stream empfangen kann. Wenn Ihr Ziel S3-kompatibler Storage oder ein einfacher Linux-Host ist, verwenden Sie ein dafür geeignetes Tool. restic-Backups von einem VPS beschreibt diesen Weg.

Warum verwendet ZFS so viel RAM? Der ARC

Der ARC (Adaptive Replacement Cache) ist der Lesecache von ZFS. Er befindet sich im Kernel-Speicher und nicht im normalen Linux Page Cache. Daher führt free -h ihn nicht unter buff/cache auf. Er wird als verwendeter Speicher angezeigt. Ein ZFS-System, das nahezu voll wirkt, hat in der Regel einen gut gefüllten Cache. Das erklärt die meisten Meldungen, dass „ZFS meinen RAM aufgefressen hat“.

Das Standardlimit ist bewusst großzügig bemessen. OpenZFS 2.3 setzt die maximale ARC-Größe auf den größeren Wert aus RAM minus 1 GiB und 5/8 des RAM. OpenZFS 2.2 und ältere Versionen verwendeten unter Linux die Hälfte des RAM. FreeBSD verwendete bereits die neuere Regel. Führen Sie zfs version aus, um festzustellen, welche Regel für Ihr System gilt.

[
  {
    "label": "2 GB VPS",
    "openzfs_2_2_linux_gib": 1,
    "openzfs_2_3_gib": 1.25
  },
  {
    "label": "4 GB VPS",
    "openzfs_2_2_linux_gib": 2,
    "openzfs_2_3_gib": 3
  },
  {
    "label": "8 GB VPS",
    "openzfs_2_2_linux_gib": 4,
    "openzfs_2_3_gib": 7
  },
  {
    "label": "16 GB VPS",
    "openzfs_2_2_linux_gib": 8,
    "openzfs_2_3_gib": 15
  }
]

Diese Werte sind die dokumentierte Standardregel, angewendet auf gängige Instanzgrößen. Sie stammen nicht von einem laufenden System. Bei einer Instanz mit 4 GB erlaubt die Regel von 2.3 einen ARC von 3 GiB. Dasselbe System mit 2.2 begrenzt den ARC unter Linux auf 2 GiB. Eine Instanz mit 2 GB erlaubt nach der Regel von 2.3 weiterhin 1.25 GiB. Ihrer Anwendung steht der verbleibende Speicher zur Verfügung.

Lesen Sie die tatsächlichen Werte direkt von Ihrem Server ab, statt sich auf die Tabelle zu verlassen:

grep -E '^(size|c_max) ' /proc/spl/kstat/zfs/arcstats
arc_summary | head -n 20

Die dritte Spalte enthält Bytes. c_max ist die derzeit geltende Obergrenze. size gibt an, wie viel Speicher der ARC aktuell belegt.

Der ARC gibt Speicher durchaus wieder frei. Der Kernel signalisiert Speicherdruck, und der ARC wird verkleinert. Das Problem ist der Zeitpunkt. Die Verkleinerung wird durch diesen Speicherdruck ausgelöst. Daher kann ein Prozess, der auf einmal mehrere hundert MiB anfordert, den OOM-Killer (Out of Memory) auslösen, während der ARC noch Speicher freigibt. Auf einem System mit 2 GB, auf dem eine Datenbank und ein Webserver laufen, ist das kein seltenes Ereignis. Das OpenZFS-Handbuch beschreibt manuelle Änderungen ebenso: Das Absenken des Limits „führt nicht dazu, dass der ARC ohne Speicherdruck verkleinert wird, der die Verkleinerung auslöst“.

Begrenzung des ARC auf einem kleinen VPS

Legen Sie zuerst den Speicherbedarf der Workload fest. Addieren Sie den Bedarf der Datenbank und der Anwendung, lassen Sie eine Reserve für das Betriebssystem und weisen Sie den verbleibenden Speicher dem ARC zu. Bei einer Instanz mit 4 GB, auf der Postgres und eine Webanwendung laufen, sind 512 MiB bis 1 GiB ARC ein sinnvoller Ausgangspunkt.

Setzen Sie den Wert zur Laufzeit in Bytes. Dieser Wert entspricht 1 GiB.

echo 1073741824 | sudo tee /sys/module/zfs/parameters/zfs_arc_max

Machen Sie die Einstellung rebootfest.

echo 'options zfs zfs_arc_max=1073741824' | sudo tee /etc/modprobe.d/zfs.conf
sudo update-initramfs -u

Der Schritt für initramfs ist wichtig, weil das Modul aus initramfs geladen werden kann, bevor das Root-Dateisystem eingehängt ist. In diesem Fall würde es die gerade erstellte Datei nicht einlesen. Prüfen Sie nach dem Reboot den Wert anhand der c_max-Zeile aus arcstats.

Zwei Einschränkungen ergeben sich direkt aus dem Handbuch. Sie können den Wert im laufenden System nicht wieder auf 0 setzen. Um die Einstellung zurückzunehmen, müssen Sie die Datei bearbeiten und einen Reboot durchführen. Außerdem verkleinert eine niedrigere Einstellung einen großen ARC nicht sofort.

Unter FreeBSD befindet sich dieselbe Begrenzung unter vfs.zfs.arc als sysctl. Führen Sie sysctl vfs.zfs.arc aus, um die aktuellen Werte und den genauen Namen für Ihre Version anzuzeigen. Schreiben Sie den Maximalwert anschließend in /boot/loader.conf.

Für einen kleinen Server gelten zwei weitere Regeln zum Speicher. Lassen Sie die Deduplizierung deaktiviert, weil die Deduplizierungstabelle im Speicher liegt. Als häufig veröffentlichte Faustregel gelten 1 bis 3 GB RAM pro TB eindeutiger Daten. Verwenden Sie außerdem kein Swap auf einem zvol, also einem aus dem Pool ausgeschnittenen Blockgerät. Das Swapping über das Dateisystem, das gerade Speicher freigeben soll, kann zu einem Deadlock des Systems führen. Verwenden Sie Swap auf einer normalen Partition oder in einer Swap-Datei außerhalb des Pools.

Wann ext4 oder XFS zusammen mit restic die bessere Lösung ist

ZFS spielt seine Vorteile auf einem Server mit ausreichend Arbeitsspeicher und einem zweiten Volume aus. In allen anderen Fällen ist ein einfaches Dateisystem zusammen mit einem geeigneten Backup-Tool die bessere Wahl. Wählen Sie ext4 oder XFS, wenn:

• Die Instanz über 2 GB oder 4 GB RAM verfügt und die Workload den gesamten Arbeitsspeicher benötigt.
• Es nur eine virtuelle Festplatte und keine zweite Kopie gibt. ZFS erkennt dann zwar Fehler, kann sie aber nicht beheben.
• Ihr Backup-Ziel Object Storage oder ein einfacher Linux-Host ist und dort kein zfs send-Stream empfangen werden kann.
• Sie Debian mit DKMS betreiben und sich kein Kernel-Upgrade leisten können, nach dem das Modul nicht gebaut wurde.
• Sie ZFS auf dem Root-Dateisystem benötigen und die Images des Anbieters nur ext4 anbieten.

Behalten Sie ZFS bei, wenn Sie über ein separates Daten-Volume, ausreichend Arbeitsspeicher (8 GB und mehr sind komfortabel) und einen Plan verfügen, der Snapshots und zfs send tatsächlich nutzt, statt sie nur zu aktivieren. In allen anderen Fällen deckt ext4 mit restic, das verschlüsselte und deduplizierte Backups auf einen Speicher schreibt, den der Server nicht kontrolliert, den größten Teil desselben Bedarfs ab, ohne den zusätzlichen Speicherverbrauch.

Fehlerbilder und die angezeigten Meldungen

Der Pool ist nach einem Reboot verschwunden. zpool status gibt no pools available aus. Der Importdienst liest /etc/zfs/zpool.cache. Ein Pool, der in dieser Datei fehlt, wird beim Booten daher nie importiert. sudo zpool import zeigt, welche Pools importiert werden können, sudo zpool import tank importiert ihn wieder, und sudo zpool set cachefile=/etc/zfs/zpool.cache tank sorgt dafür, dass er dauerhaft eingetragen bleibt. Ein Pool, der auf einem anderen System nicht sauber exportiert wurde, meldet cannot import 'tank': pool may be in use from other system. sudo zpool import -f tank setzt diese Meldung außer Kraft, sobald Sie sicher sind, dass kein anderer Host den Pool verwendet.

modprobe: FATAL: Module zfs not found in directory /lib/modules/6.12.0-... unter Debian nach einem Kernel-Upgrade. DKMS wurde für den neuen Kernel nicht gebaut, meistens weil die passenden Header nicht installiert sind. dkms status zeigt, was für welchen Kernel gebaut wurde. sudo apt install -y linux-headers-$(uname -r) führt anschließend sudo dkms autoinstall aus und baut das Modul neu. sudo zpool import tank stellt den Pool danach wieder her.

Der Pool ist voll, obwohl Sie die Dateien gelöscht haben. Gelöschte Daten bleiben auf dem Datenträger, solange ein Snapshot noch auf sie verweist. Deshalb zeigen du und df unterschiedliche Werte. zfs list -o space -r tank teilt die Belegung in USEDDS und USEDSNAP auf. Ein hoher USEDSNAP-Wert liefert die Erklärung. Löschen Sie die alten Snapshots mit sudo zfs destroy tank/data@2026-06-01. Danach wird der Speicherplatz wieder freigegeben.

Die CKSUM-Zähler in zpool status steigen. Eine Komponente unterhalb von ZFS hat fehlerhafte Daten geliefert. Bei einem Mirror ist der Zähler eine Warnung, und der Block wurde repariert. Bei einem Pool mit nur einem Datenträger ist die Datei verloren. zpool status -v nennt ihren Namen. Stellen Sie diese einzelne Datei aus einem Backup wieder her, das nicht in diesem Pool liegt.

Der Server ist langsam und verwendet Swap. Begrenzen Sie den ARC wie oben beschrieben. Führen Sie anschließend arc_summary aus und prüfen Sie die Trefferquote. Ein ARC, der die Arbeitsmenge nicht aufnehmen kann, führt dazu, dass jeder Lesezugriff auf den Datenträger geht. An diesem Punkt wäre ein einfaches Dateisystem mit dem Page Cache die bessere Lösung.

FAQ

Wie viel RAM benötigt ZFS auf einem VPS?

ZFS läuft auf einer Instanz mit 2 GB. Entscheidend ist, wie viel RAM für Ihre Anwendung übrig bleibt. Ohne Anpassung lässt OpenZFS 2.3 den ARC bis zum größeren Wert aus RAM minus 1 GiB und 5/8 des RAM wachsen. Auf einem System mit 4 GB kann der Cache daher 3 GiB belegen. Setzen Sie zfs_arc_max auf einen Wert, den Ihre Arbeitslast entbehren kann. Prüfen Sie anschließend den Wert in der Zeile c_max aus /proc/spl/kstat/zfs/arcstats.

Ist ein ZFS-Snapshot ein Backup?

Nein. Ein Snapshot befindet sich im selben Pool wie die Daten. Er übersteht einen fehlerhaften rm und ein fehlgeschlagenes Upgrade. Zusammen mit dem Pool oder der Instanz geht er jedoch verloren. Machen Sie daraus ein Backup, indem Sie ihn mit zfs send an einen anderen Rechner senden. Alternativ können Sie ein Backup-Tool ausführen, das auf einen Speicher schreibt, den dieser Server nicht kontrolliert.

Funktioniert ZFS unter FreeBSD und Linux gleich?

Seit OpenZFS 2.0 im Dezember 2020 verwenden beide dieselbe Codebasis, dieselben Befehle und dasselbe On-Disk-Format. Pools können zwischen den Systemen verschoben werden. Der Unterschied liegt in der Paketierung. FreeBSD liefert ZFS im Basissystem aus. Unter Linux entscheidet jede Distribution selbst: Ubuntu integriert das Modul in seine Kernelpakete. Debian erstellt es dagegen auf Ihrem Rechner mit DKMS. Nach einem Kernel-Upgrade kann das Modul daher fehlen, bis der Neuaufbau erfolgreich abgeschlossen ist.

Kann ZFS die Beschädigung auf einem VPS mit einer Festplatte reparieren?

ZFS erkennt die Beschädigung und nennt die betroffene Datei. Es kann sie jedoch nicht reparieren, weil die Reparatur eine zweite Kopie des Blocks benötigt. zfs set copies=2 auf einem Dataset stellt diese zweite Kopie bereit und benötigt dafür doppelt so viel Speicherplatz. Damit lässt sich ein beschädigter Block behandeln, nicht jedoch ein verlorenes Volume. Ein Mirror über zwei Volumes ist die Lösung, die die Daten tatsächlich repariert.

Verlangsamt Komprimierung den Server?

lz4 macht den Server in der Regel schneller. Komprimierte Blöcke bedeuten weniger geschriebene und gelesene Bytes. Die CPU-Kosten pro Block sind gering im Vergleich zur eingesparten Festplattenarbeit. Setzen Sie compression=lz4 am Pool-Root, damit jedes Dataset diese Einstellung übernimmt. Prüfen Sie anschließend zfs get compressratio tank, sobald echte Daten geschrieben wurden.