ZFS, Btrfs und ext4 können Jellyfin-Medien schnell genug für die gewöhnliche Wiedergabe speichern. Die Entscheidung für ein Dateisystem hängt daher weniger vom Durchsatz beim Film-Streaming ab, sondern vielmehr davon, wo Prüfsummen, Snapshots, Redundanz, Replikation, Reparaturwerkzeuge und die betriebliche Komplexität angesiedelt sein sollen.
Dieser Vergleich bezieht sich ausschließlich auf das Massenspeichervolumen für Medien. Jellyfin-App-Daten und die SQLite-Datenbank weisen ein anderes Verhalten bei zufälligen I/O-Vorgängen auf und sollten separat dimensioniert und abgestimmt werden, anstatt für jede Speicherrolle dieselben Dateisystemrichtlinien zu erzwingen.
ZFS eignet sich, wenn der Medien-Pool zugleich das Integritätssystem ist
ZFS kombiniert Dateisystem, Volume-Management, Prüfsummen, Snapshots, Scrubs sowie RAIDZ oder Spiegelungen in einem einzigen Speichermodell. Das ist attraktiv, wenn von einem Medien-Pool mit mehreren Laufwerken erwartet wird, dass er Beschädigungen erkennt und beschädigte Blöcke dank Redundanz aus einer intakten Kopie repariert.
OpenZFS dokumentiert das grundlegende Integritätsverhalten direkt: Jeder Block wird mit einer Prüfsumme versehen, Scrubs überprüfen den Pool, und redundante Spiegelungen oder RAIDZ können beschädigte Daten aus einer intakten Kopie reparieren. Damit eignet sich ZFS besonders gut, wenn der Medien-Pool selbst für Integrität und Reparaturen zuständig sein soll.
Wähle ZFS, wenn du Snapshots, Scrubs, Replikation und Redundanz tatsächlich betreiben wirst. Wähle es nicht nur, weil ein Medienserver-Leitfaden es als „Enterprise“ bezeichnet.
Btrfs eignet sich für einen Linux-nativen Workflow mit Snapshots und Prüfsummen
Btrfs ist in Linux integriert und bietet Copy-on-Write, Daten- und Metadatenprüfsummen, Snapshots, Komprimierung sowie Send/Receive. Es kann gut für eine einzelne Mediendisk, eine Spiegelung oder einen vielseitig genutzten Linux-Server funktionieren, auf dem das Dateisystem auch andere Container- und Host-Workflows unterstützt.
Die Btrfs-Dokumentation beschreibt Copy-on-Write-Speicher mit Snapshots, Daten- und Metadatenprüfsummen, Komprimierung, Volume-Management und Funktionen zur Selbstheilung. Diese integrierten Funktionen sind der Grund, ein funktionsreicheres Dateisystem als ext4 für einen Linux-nativen Medienhost zu akzeptieren.
Sei bei Redundanzprofilen konservativ. Verwende ein Layout, von dem du dich sicher wiederherstellen kannst, anstatt eine Funktion auszuwählen, nur weil sie die Rohkapazität maximiert.
ext4 eignet sich, wenn das Dateisystem unkompliziert bleiben soll
ext4 ist ein ausgereiftes Journaling-Dateisystem mit umfassender Linux-Unterstützung und vertrauten Reparaturwerkzeugen. Es bietet keine durchgängigen Datenprüfsummen nach dem Vorbild von ZFS und keine nativen Dateisystem-Snapshots. Diese Aufgaben müssen daher von mdraid, LVM, einer Backup-Software, der NAS-Schicht oder einem anderen Werkzeug übernommen werden.
Die Dokumentation des Linux-Kernels beschreibt das Journal von ext4 als Mechanismus, der die Konsistenz der Dateisystem-Metadaten bei Abstürzen schützt. ext4 versucht nicht, dasselbe integrierte Modell für Pools, Snapshots und durchgängige Integrität wie ZFS bereitzustellen. Daher eignet es sich am besten, wenn diese Aufgaben bewusst von anderen Schichten übernommen werden.
Diese Einfachheit kann für eine Medienbibliothek wertvoll sein, die bereits gesichert wird und für die das Dateisystem nicht die wichtigste Wiederherstellungsplattform sein muss.
Der Jellyfin-Mediendurchsatz entscheidet diesen Vergleich nur selten
Ein Film im Direct-Play-Modus besteht größtenteils aus sequenziellen Lesevorgängen. Jedes gesunde Dateisystem auf geeigneter Hardware kann gängige Medienbitraten übertreffen, daher sollten kleine Benchmark-Unterschiede die Wahl nicht dominieren.
Die wichtige Änderung der Arbeitslast tritt auf, wenn mehrere Streams, Scans, Downloads, Backups, Snapshots oder andere Dienste auf denselben Pool zugreifen. Dann sind Layout, Laufwerksanzahl, Cache-Verhalten, Fragmentierung und Wiederherstellungsrichtlinien wichtiger als der Jellyfin-Prozess selbst.
Der ZimaSpace-Leitfaden zu durch Snapshots verursachtem Wachstum von Btrfs-Metadaten erinnert daran, dass fortschrittliche Dateisystemfunktionen neben Wiederherstellungsoptionen auch Wartungsaufgaben schaffen.
Wähle nach dem Workflow für Ausfälle und Wiederherstellung
| Priorität | Beginne mit | Warum |
|---|---|---|
| Integrierte Integrität über mehrere Laufwerke und RAIDZ | ZFS | Prüfsummen, Scrub, Snapshots, Redundanz auf Pool-Ebene |
| Linux-natives CoW, Snapshots, flexible Nutzung mit einem Laufwerk oder einer Spiegelung | Btrfs | Snapshots, Prüfsummen, Send/Receive |
| Einfaches, ausgereiftes Dateisystem; Wiederherstellung wird anderweitig übernommen | ext4 | Geringere Komplexität bei den Speicherrichtlinien |
Unabhängig vom gewählten Dateisystem solltest du ein echtes Backup vorhalten. Snapshots und RAID können einige Ausfallrisiken verringern, ersetzen aber keine unabhängige Kopie gegen Löschung, Ransomware, den vollständigen Verlust des Pools oder einen fehlerhaften administrativen Vorgang.
Wähle das Dateisystem, dessen Ausfallmodi und Wiederherstellungswerkzeuge du praktisch erproben kannst. Das beste Jellyfin-Medienvolumen ist nicht das mit der längsten Funktionsliste, sondern das, von dem du dich vorhersehbar wiederherstellen kannst, wenn die Funktionsliste eines Tages keine Rolle mehr spielt.
Produktvergleiche
Mehr zum Lesen

Integrierte Jellyfin-Backups vs. Backups auf Dateiebene: Welche sollten Sie verwenden?
Verwenden Sie die integrierten Jellyfin-Backups zur bequemen Wiederherstellung des App-Zustands; verwenden Sie angehaltene Backups auf Dateiebene, wenn die Wiederherstellung auch den umfassenderen Zustand des...

Jellyfin mit Kodi vs. eigenständige Jellyfin-Clients: Was passt besser?
Wählen Sie Kodi für einen anpassbaren, TV-orientierten Workflow mit mehr Client-seitigem Status; wählen Sie eigenständige Jellyfin-Clients für eine einfachere, geräteübergreifende, servergesteuerte Nutzung.

Mehr CPU-Kerne für Jellyfin: Wann wird es dadurch tatsächlich schneller?
Mehr Kerne wirken sich auf Jellyfin erst dann aus, wenn ein kontrollierter Kandidat mit weniger Kernen CPU-limitiert ist und derselbe Workload auf dem größeren...

