ZFS 2.3 veröffentlicht, mit RAIDZ-Erweiterungsfunktion

 (github.com/openzfs)
1 Punkte von GN⁺ 2025-01-15 | 1 Kommentare | Auf WhatsApp teilen
  • OpenZFS 2.3.0 enthält als Kernfunktion die RAIDZ Expansion, mit der sich durch das Hinzufügen neuer Geräte zu einem bestehenden RAIDZ-Pool die Kapazität ohne Downtime erhöhen lässt
  • Fast Dedup verbessert die Leistung der bestehenden Deduplizierungsfunktion deutlich, zusätzlich gibt es Performance-Verbesserungen in der gesamten Codebasis
  • Direct IO ermöglicht es, bei Lese-/Schreibvorgängen den ARC zu umgehen, und zielt damit auf Umgebungen wie NVMe-Geräte ab, in denen Caching die Effizienz verringern kann
  • Hinzu kommen optionale JSON-Ausgabe für häufig genutzte Befehle, Unterstützung für Datei- und Verzeichnisnamen mit bis zu 1023 Zeichen sowie wichtige Bugfixes für Probleme aus früheren Versionen
  • Unterstützt werden Linux-Kernel 4.18~6.12 sowie FreeBSD 13.3 und 14.0~14.2; an diesem Release-Zyklus waren 134 Personen beteiligt

Was sich in OpenZFS 2.3.0 geändert hat

  • OpenZFS 2.3.0 wurde vor allem bei Speichererweiterung, Deduplizierungsleistung, I/O-Pfad, Befehlsausgabeformat und Unterstützung für längere Dateinamen aktualisiert
  • Das Release-Tag ist zfs-2.3.0 und enthält die Änderungen seit OpenZFS 2.2.0

Speichererweiterung und Performance-Verbesserungen

  • RAIDZ Expansion ermöglicht es, einem bestehenden RAIDZ-Pool neue Geräte hinzuzufügen und so die Speicherkapazität ohne Downtime zu erhöhen
  • Fast Dedup ist ein bedeutendes Performance-Upgrade für die bestehende Deduplizierung in OpenZFS
  • Direct IO erlaubt die Umgehung des ARC bei Lese-/Schreibvorgängen
    • Ziel sind Leistungsverbesserungen in Situationen, in denen Caching die Effizienz beeinträchtigen kann, etwa bei NVMe-Geräten
  • Zusätzlich sind mehrere Performance-Verbesserungen in der gesamten Codebasis enthalten

Befehlsausgabe und Namenslängen

  • JSON fügt den am häufigsten genutzten Befehlen eine optionale JSON-Ausgabe hinzu
  • Long names unterstützt Datei- und Verzeichnisnamen mit bis zu 1023 Zeichen

Stabilität, Plattformen und Beiträge

  • Enthalten sind wichtige Bugfixes, die in früheren Versionen gemeldete Probleme beheben
  • Unterstützte Plattformen:
    • Linux-Kernel 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • An diesem Release-Zyklus haben sich 134 Beitragende beteiligt

Dokumentation und Changelog

Änderungen an Moduloptionen

  • Alle Optionen und ihre Steuerungsziele sind in der Dokumentation zu module parameters zusammengefasst
  • Zu den neuen Moduloptionen gehören Einträge zu RAIDZ-Erweiterung, Deduplizierungslog, Direct IO, Allocator, Scrub und Resilver
    • Beispiele: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • Entfernte Moduloptionen:
    • zfetch_array_rd_sz
  • Geänderte Moduloptionen:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-01-15
Meinungen auf Hacker News

  • Die seit Jahren vorbereitete ZFS-RAIDZ-Erweiterung ist endlich enthalten
    Die wichtigsten Neuerungen sind RAIDZ-Erweiterung, mit der sich durch Hinzufügen von Geräten zu einem bestehenden RAIDZ-Pool die Kapazität ohne Unterbrechung erhöhen lässt, schnelle Deduplizierung, die die Performance der OpenZFS-Deduplizierung deutlich steigert, Direct I/O, das den ARC umgeht und die Performance in Umgebungen verbessert, in denen Caching wie bei NVMe ineffizient sein kann, optionale JSON-Ausgabe für häufig genutzte Befehle sowie Unterstützung für Datei- und Verzeichnisnamen mit bis zu 1023 Zeichen

    • Genauer gesagt bedeutet das, dass man einem bestehenden RAIDZ-vdev neue Geräte, also Disks, hinzufügen kann
    • Wenn man Proxmox auf ZFS und NVMe betreibt, frage ich mich, ob es besser wäre, Direct I/O zu aktivieren, sobald 2.3 ausgerollt ist
      Ich würde gern wissen, für welche Anwendungsfälle diese Funktion gedacht ist
    • Die ersten vier Punkte wirken wirklich wie große Änderungen
    • vdev removal dürfte aber wohl weiterhin nicht möglich sein
    • Ich frage mich, wie gut diese Funktion zusammen mit Verschlüsselung getestet wurde
      Außerdem bezweifle ich, ob das ZFS-Team Verschlüsselung wirklich als Priorität erster Klasse behandelt
      ZFS unter Linux hat viel vom Ruf von ZFS unter Solaris geerbt, aber wer es in Produktionsumgebungen einsetzt, sollte sich den Issue Tracker ziemlich genau ansehen, um die Realität zu sehen

  • Es ist unverständlich, dass es unter Windows, der nach Nutzerzahlen mit Abstand größten PC-Plattform, immer noch keine Antwort auf ZFS gibt
    Microsoft hatte WinFS und danach ReFS, aber beides wurde zurückgestellt; die Entwicklung läuft zwar weiter und gelegentlich landen Teile davon in Win11, doch ein offizielles Release ist nicht in Sicht
    Einige Einzelpersonen versuchen sich an der großen Aufgabe, eine ZFS-Kompatibilitätsschicht zu bauen, aber das ist noch weit von Reife oder Praxistauglichkeit entfernt
    Ich verstehe nicht, wie Windows immer noch ein 32 Jahre altes Dateisystem verwenden kann

    • Ehrlich gesagt ist die Lage unter Linux auch nicht viel besser
      Bei ZFS gibt es unter Linux Lizenzprobleme, die eine vollständige Integration verhindern, und Btrfs ist zwar seit 15 Jahren in Entwicklung, erreicht ZFS aber bei Funktionen und Stabilität immer noch nicht
      Die meisten Linux-Distributionen nutzen weiterhin standardmäßig das 19 Jahre alte ext4, wobei ext4 im Grunde auch eher Erweiterungen auf dem gleich alten ext2 wie NTFS aufsetzt
      Fairerweise gibt es nur wenige Betriebssystemkomponenten, die so wichtig sind wie das Dateisystem, und viele wollen ein Dateisystem nicht anfassen, wenn es nicht mehr als zehn Jahre in Produktionsumgebungen bewährt ist
    • Der Grund ist einfach: Den Großteil der Last, die das Dateisystem tragen müsste, übernimmt die Enterprise-Storage-Hardware, auf der dieses Dateisystem liegt
      Funktionen wie Snapshots, Deduplizierung auf Blockebene, Object-Storage-Techniken, RAID/Resilienz und Größenänderung werden von den Storage-Systemen erledigt
      Moderne Storage-Appliances sind fast schon schwarze Magie, daher braucht NTFS nicht zwingend mehr Funktionen
      Man greift transparent über NAS/SAN darauf zu oder speichert NTFS-Volumes auf einer leistungsfähigen Disk-Box
      Im High-End-Bereich der Linux-Welt gibt es Lustre und GPFS, während ZFS im Allgemeinen für Anwendungsfälle passt, bei denen Performance nicht im Mittelpunkt steht, aber Resilienz nötig ist
    • Auch im Mainline-Linux-Kernel gibt es keine Antwort auf ZFS
      Ich denke, weil es schwierig und riskant ist, während die Belohnung meist nur in technischer Anerkennung besteht
    • Aus Sicht eines Endnutzers, der Windows und Linux nutzt, aber kein ZFS: Ich frage mich, was mir entgeht
    • OpenZFS für Windows hat den Release-Candidate-Status erreicht (rc11), und es gibt noch ein paar verbleibende Bugs rund um das Mounten von Volumes
      Sie sind nicht gravierend, aber derzeit sollte man Verschlüsselung besser meiden; die Entwicklung läuft schnell genug, dass alle paar Wochen ein neuer Release Candidate erscheint, um die verbleibenden Probleme zu beheben
      Kombiniert man das mit Storage Spaces, um Disks unterschiedlicher Art oder Größe zu poolen und Platzierung, Redundanz und Tiering pro Space zu definieren, wird Windows inzwischen zu einer fortgeschrittenen Storage-Plattform
      Mit Windows Server, etwa dem günstigen 2022/2025 Essentials, kann man im LAN und auf virtuellen Festplatten im Format .vhdx auch SMB Direct/RDMA mit bis zu 10 Gbyte/s nutzen, was eine schnellere Alternative zu iSCSI ohne Konfigurationsaufwand ist
      Deshalb habe ich napp-it cs, eine ZFS-Web-GUI, von Solaris auf Windows portiert, damit sich Storage Spaces, ZFS und entfernte OpenZFS-Server wie Proxmox verwalten lassen; für nichtkommerzielle Nutzung ist es kostenlos

  • Mir gefällt, dass die Erweiterungsfunktion ziemlich konservativ umgesetzt wurde.
    Die Erweiterung ist nicht nur vollständig transparent und wiederaufnehmbar, sondern behält während des gesamten Vorgangs auch die Redundanz bei.
    Es gibt allerdings einen kleinen Vorbehalt, den man kennen sollte.
    Auch nach Abschluss der Erweiterung behalten bestehende Blöcke ihr altes Verhältnis von Daten zu Parität bei. Ein 5-wide RAIDZ2 wird zum Beispiel weiterhin mit 3 Daten- zu 2 Paritätsblöcken über die größere Menge an Festplatten verteilt.
    Neue Blöcke werden mit dem neuen Verhältnis von Daten zu Parität geschrieben. Wenn man etwa ein 5-wide RAIDZ2 einmal erweitert und daraus 6-wide wird, sind es 4 Daten- zu 2 Paritätsblöcken.

    • Ich bin mir nicht sicher, ob das wirklich ein Vorbehalt ist. Es bedeutet nur, dass bestehende Daten in einer nicht optimalen Anordnung verbleiben können.
      Der Vorteil von RAIDZ N bleibt trotzdem erhalten: Der Pool läuft weiter, selbst wenn bis zu N Festplatten komplett ausfallen.
    • Dieser Vorbehalt ist ein gut erwartbares Verhalten. Bei ZFS-Funktionen sollte man im Allgemeinen davon ausgehen, dass bestehende Blöcke nicht neu geschrieben werden.
      Zum Beispiel gelten auch Konfigurationsänderungen nur für neue Daten.
    • Ehrlich gesagt ist das ein ziemlich großer Vorbehalt.
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      Dabei steht ___ für freien Platz. Wenn man eine Festplatte hinzufügt und erweitert, würde man logisch etwa Folgendes erwarten:
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      So wie ich es verstehe, wird tatsächlich aber eher so erweitert:
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Dabei sind die Blöcke Dd1 bis 3 einfach verschwendet. Das heißt: Wenn man dem Array eine neue Festplatte hinzufügt, wächst der freie Speicherplatz nur um 25 %.
      Wenn man zum Beispiel mit 8-TB-Festplatten ursprünglich insgesamt 24 TB nutzbaren Speicher hat und vor der Erweiterung 4 TB frei waren, sind es nach der Erweiterung 5 TB frei.
      Ich hoffe, jemand sagt mir, dass ich das falsch verstanden habe. Falls nicht, wirkt das wie eine ziemlich nutzlose Implementierung.

  • Für ZFS-Nutzer ist das eine große Nachricht. Vermutlich besonders für Hobby- und Heimnutzer, aber trotzdem groß.
    RAIDZ-Erweiterung war seit Jahren eine der am häufigsten gewünschten Funktionen.

    • Ich bin mit ZFS noch nicht vertraut und habe es auch in den Release Notes nicht gefunden, aber ich frage mich, ob die Erweiterung nur mit Festplatten gleicher Größe funktioniert.
      Ich würde gern wissen, ob man größere oder kleinere Festplatten hinzufügen kann oder ob alle Festplatten gleich groß sein müssen.

  • Das ist eine Online-Erweiterung. Erweiterung an sich war früher schon möglich, aber dafür musste man das Array herunterfahren.
    Auch der Umzug auf größere Laufwerke war möglich, aber man musste sie einzeln ersetzen, und natürlich bekam man die neue Kapazität erst, nachdem alle Laufwerke aufgerüstet waren.
    Soweit ich weiß, ist das Verkleinern eines Pools weiterhin nicht möglich. Wenn man also einem Pool mit fünf Laufwerken ein sechstes hinzufügt, kann man nicht wieder auf fünf zurück, selbst wenn nur sehr wenige Daten darauf liegen.

  • Endlich!
    Damit werden sogar grenzwertig verrückte Single-vdev-Konfigurationen wie RAID-Z3 mit vier der teuersten und dichtesten Festplatten möglich, die man aktuell kaufen kann.
    Anfangs hat man wegen der Redundanz von drei Festplatten nur 25 % effektive Platzausnutzung, aber jedes Mal, wenn der Speicherbedarf wächst, kann man eine weitere Festplatte kaufen und bis auf etwa 12 Stück erweitern.
    Mit der Zeit fallen die Festplattenpreise, und weil man die Festplatten zu unterschiedlichen Zeitpunkten hinzufügt, verteilt sich auch die Ausfallwahrscheinlichkeit.

    • Stimmt, aber man sollte auch den Geschwisterkommentar ansehen.
      Wenn man das Array erweitert, werden bestehende Daten nicht effizienter gespeichert.
      Um das neue Verhältnis von Parität zu Daten zu bekommen, muss man die Daten zwangsweise kopieren und die alte ineffiziente Version löschen. Dafür bräuchte man zum Beispiel so ein Tool [1].
      Persönlich halte ich es für deutlich besser, jeweils vollständige RAID-Z-Konfigurationen zu kaufen und eine neue Konfiguration hinzuzufügen oder alte Konfigurationen Festplatte für Festplatte zu ersetzen.
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • Ich frage mich, wie ZFS im Vergleich zu btrfs abschneidet
    Auf meinem Homeserver nutze ich derzeit btrfs, hatte aber schon ein paar seltsame Probleme
    Ich überlege, auf ZFS umzusteigen, möchte aber nicht in dieselbe Lage geraten

    • Ich habe btrfs erstmals vor 15 Jahren, ungefähr zu Zeiten von Linux 2.6.33-rc4, ausprobiert
      Nach drei Tagen hatte ich eine Datei, die sich nicht löschen ließ, und habe die Nutzung beendet; später bin ich auf ZFS gestoßen
      Auch ZFS hatte ein paar weniger gravierende Probleme, aber damals war ich Informatikstudent, und verglichen mit den Problemen, die ich mit btrfs hatte, wirkten sie klein genug, dass ich dachte, ich könnte sie beheben
      In den folgenden 18 Monaten behob ich alle störenden Probleme und schickte Patches an das damalige ZFSOnLinux-Repository; diese Arbeit half dabei, ZFS unter Linux für den Produktivbetrieb nutzbar zu machen
      Seitdem nutze ich durchgehend ZFS, und es hat gut funktioniert
      Wäre der Zustand von btrfs besser gewesen, wäre ich wohl btrfs-Contributor geworden. Aber nicht nur war der Zustand damals schlecht; auch danach, wann immer ich es für ernsthafte Zwecke ausprobierte, standen mir weiterhin Probleme im Weg, etwa häufige ENOSPC-Fehler, obwohl noch Speicherplatz vorhanden war
      ZFS hingegen funktioniert einfach. Ich und viele andere haben viel Arbeit investiert, damit es gut funktioniert
      Der größte Unterschied war, dass ZFS eine sehr solide Grundlage hatte, dank einer hervorragenden Infrastruktur für Regressionstests
      Eine User-Space-Version führt den Code zufällig aus, um Bugs zu finden, bevor sie in der Produktionsumgebung zuschlagen, und für jede vorgeschlagene Änderung wird eine Testsuite ausgeführt, um Bugs abzufangen
      Bei ZFS prüfen außerdem mehr Leute vorgeschlagene Änderungen als bei anderen Dateisystemen. Auch Btrfs-Entwickler sagen oft, dass es zwischen den beiden Dateisystemen einen großen Unterschied bei der Manpower gibt; ich meine mich zu erinnern, dass von ungefähr Faktor 6 die Rede war
      Jedenfalls bereuen nur wenige den Einsatz von ZFS, also wird es dir vermutlich gefallen
    • ZFS wird seit fast 20 Jahren im Produktivbetrieb eingesetzt
      Laut BTRFS-Dokumentation ist BTRFS noch nicht vollständig für den Produktivbetrieb geeignet: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      Einige einfache Use Cases kann man mit BTRFS durchaus als produktionsreif ansehen, aber das Ergebnis hängt von der jeweiligen Umgebung ab
    • btrfs verfolgt ähnliche Ziele wie ZFS, ist aber deutlich weniger ausgereift
      Ich habe es für die Root-Partition genutzt, weil kein DKMS nötig ist, hatte aber viele Probleme
      Ich habe es ziemlich simpel nur als Mirror verwendet, doch als eines Tages ein Laufwerk im Array Probleme bekam, hielt btrfs dem nicht richtig stand
      Soweit ich mich erinnere, wurde alles read-only neu eingehängt, und standardmäßig lief es nicht im degraded mode
      Selbst mdraid ohne Funktionen wie Checksums wäre besser gewesen
      ZFS markiert ein Array ebenfalls als fehlerhaft, lässt es einen aber selbstverständlich weiterverwenden
      Dass das Standardverhalten kein RAID war, also dass der R-Teil, der die Daten wieder einliest, faktisch fehlte, hat mein Vertrauen zerstört
      Seit dem Umstieg auf ZFS hatte ich keine Probleme mehr, und es gibt auch deutlich mehr Community und gute Tools
    • Ich habe Btrfs einige Jahre genutzt und bin vor ein paar Jahren davon weggegangen
      Auch mit Btrfs gab es ein- oder zweimal seltsame Dinge, aber letztlich konnte ich alles wiederherstellen
      Insgesamt mochte ich die Flexibilität von Btrfs, aber in den meisten Fällen fühlte es sich zu langsam an
      Jetzt nutze ich ZFS unter Arch Linux, und bislang ist es insgesamt problemlos
      Es gibt auch mehr Tuning-Optionen und Wege, die Performance zu optimieren
      Ein Rat: Bei ZFS sollte man ausreichend recherchieren und testen. Es gibt eine gewisse Lernkurve, aber für mich hat sich der Wechsel gelohnt

  • Es ist erfreulich, dass es für NVMe-Performance nun ein ARC-Bypass gibt
    ZFS nutzt das Potenzial von NVMe eher nicht richtig aus
    Auch Online-Erweiterung könnte interessant sein
    Ich habe versucht, ZFS für eine sehr stark ausgelastete Datenbank zu verwenden, und wurde von einem Fragmentierungs-Bug hart getroffen
    Die einzige Möglichkeit, die Performance wiederherzustellen, schien darin zu bestehen, die Daten aus dem Volume herauszukopieren, das Volume zu löschen und sie dann wieder zurückzukopieren
    Vielleicht kann man jetzt einen zpool erweitern und anschließend innerhalb desselben Volumes Tablespaces kopieren, um die Fragmentierung zu reduzieren

  • Bemerkenswert ist auch, dass TrueNAS diese Funktion bereits unterstützt[0]
    Es scheint vermutlich 2.3.0rc3 zu verwenden; zur Stabilität weiß ich nichts, aber ich bin sehr gespannt
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • Kann jemand erklären, warum man zu Hause so etwas wie ZFS verwenden sollte?

    • Für mich sind die guten Gründe diese:
      Checksummen: Im Heimbereich ist die Hardwarequalität meist niedriger, deshalb ist das sogar noch wichtiger. Defekte Controller, schlechte Kabel, Festplatten, die bei höheren Temperaturen als empfohlen gelagert wurden – es gibt viele Gründe, warum falsche Daten gespeichert werden könnten, und ZFS kümmert sich gut automatisch darum, sofern Redundanz vorhanden ist.
      Snapshots: Sehr nützlich, um Backups zu erstellen und bei einem Fehler schnell zu einer älteren Version einer Datei zurückzukehren.
      Seelenfrieden: Im Vergleich zu Alternativen finde ich ZFS einfach zu bedienen, und es ist schwer, Fehler zu machen, die zu Datenverlust führen. Wenn man zum Beispiel beim Austausch eines defekten Laufwerks versehentlich das falsche Laufwerk herauszieht und der Pool dadurch unbenutzbar wird, steckt man es wieder ein und alles läuft, als wäre nichts passiert.
      Vielleicht ist mdadm heute anders, aber als ich es vor ein paar Jahren verwendet habe, hatte ich ständig Angst, einen destruktiven Fehler zu machen.
    • Um eine Antwort zu geben, die andere noch nicht genannt haben: ZFS ist gut für Steam-Spielespeicher.
      Mit recordsize=1M und compression=zstd kann man oft etwa 33 % mehr Spiele auf demselben Speicherplatz unterbringen.
      Ein Freund nutzt ZFS, um Steam-Spiele auf mehreren Festplatten zu speichern. Außerdem hat er ZFS eine SSD als L2ARC gegeben.
      ZFS cached die Spiele, die er häufig startet, automatisch auf der SSD, damit sie schneller laden.
      Wenn sich seine Lieblingsspiele ändern, passt sich ZFS automatisch an und cached diese Spiele auf der SSD.
    • Ich repliziere mit zrepl alle 10 Minuten das gesamte Dateisystem auf ein lokales NAS.
      Als meine WD_BLACK SN850 plötzlich starb [1], hat mir das schon einmal enorm geholfen.
      Auch Code, den ich durch einen klassischen git-Fehler verloren hatte, konnte ich damit wiederherstellen.
      Datenverlust durch Benutzerfehler oder den Ausfall eines einzelnen Geräts sollte heute nicht mehr möglich sein. Wir haben die Technik dafür.
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • Es gibt viele Gründe, aber für mich sind Zuverlässigkeit und Portabilität die großen.
      Es gibt kein anderes modernes Dateisystem mit Checksummen und Selbstheilung, das unter Linux, FreeBSD, Windows und macOS gelesen und beschrieben werden kann.
      Snapshots, also Boot Environments, unterstützt auch Btrfs. Meine Linux-Installation nutzt das, damit ich mir keine Gedanken über ein Third-Party-Kernelmodul zum Lesen des Root-Dateisystems machen muss.
      Die Performance ist auch nicht besonders gut; wenn unter Linux Performance das Hauptanliegen ist, ist XFS die bessere Wahl.
    • Relativ einfach, aber mächtig.
      Davor habe ich MDADM + LVM + dm-crypt + ext4 verwendet, und das funktionierte zwar auch, aber die vielen Schichten waren nervig.
      Automatische Snapshots sind sehr einfach und schnell.
      Wenn man eine Datei gelöscht hat, ist der Zugriff ebenfalls einfach: Man muss nicht den ganzen Snapshot wiederherstellen, sondern kann sie einfach aus dem versteckten Ordner .zfs/ per cp kopieren.
      Ich betreibe das seit Jahren mit sechs 8-TB-Festplatten. Mit RAIDZ2 dürfen bis zu zwei Platten ausfallen.
      Ob ich es auf einer einzelnen Platte in einem Desktop verwenden würde? Wahrscheinlich nicht.