Gründe für das Hosten von Images virtueller Datenträger im BTRFS-Dateisystem

Ich habe eine Weile über BTRFS und ZFS gelesen und obwohl ich die Vorteile von CoW beim Hosten wichtiger Dateien schätze, bin ich derzeit durch das folgende Dilemma verwirrt:

Angesichts der Tatsache, dass sowohl ZFS als auch BTRFS beim Hosten großer Dateien, die zufälligen Schreibvorgängen ausgesetzt sind (z. B. QCOW2, VDIs usw.), unter Leistungseinbußen zu leiden scheinen, warum sollte jemand BTRFS als FS der Wahl zum Hosten von VMs verwenden?

Ich weiß, dass Sie im Fall von BTRFS CoW mithilfe von chattr oder der Option nodatacow mount selektiv deaktivieren können, um die durch Fragmentierung und CoW verursachte Verschlechterung zu verringern ...

Laut Redhat deaktiviert dies jedoch auch "die Überprüfung der Prüfsumme von Daten und Metadaten, was zu einer verringerten Datenintegrität führt". (zusätzlich zu der verlorenen Kompression und natürlich der so gewünschten CoW).

Auf dieser Grundlage frage ich: Warum sollte jemand BTRFS anstelle von XFS über LVM über MD RAID wählen?

Wenn der Hauptanwendungsfall das Speichern von VM-Images oder -Datenbanken ist und Sie nicht daran interessiert sind, die potenziellen Leistungsprobleme zu akzeptieren, um die Vorteile der Datenintegrität von btrfs zu nutzen, kann ich mir keinen Grund vorstellen, warum Sie btrfs wählen möchten über xfs oder ext4.

Das Deaktivieren von Copy-on-Write nur für das VM-Image-Verzeichnis (mit Chattr + C) ist vor allem dann relevant, wenn das Speichern von VM-Images nur eine von vielen Verwendungsmöglichkeiten für Ihr Dateisystem ist. Dann kann es sehr praktisch sein, das Kopieren beim Schreiben für dieses einzelne Verzeichnis zu deaktivieren und dennoch alle Vorteile von btrfs für den Rest des Dateisystems beizubehalten.

BTRFS hat ein anderes Format auf der Festplatte, das bei einigen Schreibmustern andere Dateisysteme übertrifft. Insbesondere wurden große Anstrengungen unternommen, um das Schreiben von Metadaten auf die Festplatte zu verbessern, und es werden einige erweiterte Funktionen wie Datenprüfsummen, Komprimierung und Snapshots unterstützt. Bei großen Dateien ist eine Verbesserung der Metadatenleistung im Allgemeinen nicht wichtig.

Im Vergleich zu ZFS ist BTRFS eine einfachere Lösung und wird unter Linux besser unterstützt. Der Hauptnachteil ist, dass es nicht so gut skaliert (wenn Sie eine große Anzahl von Festplatten hinzufügen) und nicht über die gleichen Funktionen verfügt.

Im Vergleich zu XFS wird es eine Lösung mit geringerer Leistung sein. Das heißt, es wird mehr Prozessorzeit benötigen, um einen Datenblock auf die Festplatte zu schreiben, und der maximale Durchsatz wird begrenzt. Dies kann bis zu einem gewissen Grad durch Deaktivieren der Prüfsummenüberprüfung verringert werden. Dann verlieren Sie jedoch den Hauptvorteil von BTRFS gegenüber XFS, bei dem es sich um verbesserte Metadateninformationen handelt. Dh Prüfsumme und anderes Journaling (was in manchen Situationen besser sein kann).

In Bezug auf die COW-Unterstützung (Copy On Write) bevorzugt XFS die Leistung gegenüber der reinen COW-Leistung. Das heißt, XFS verfügt über sehr gute Metadaten- und Journalfunktionen in Bezug auf die Skalierbarkeit und überschreibt im Allgemeinen keine Dateidaten beim Schreiben, mit der Ausnahme, dass vorhandene Festplattenblöcke überschrieben werden können, wenn die Anwendung speziell das Überschreiben dieser Daten anfordert . Dies kann im Fall einer VM gut sein, da Ihre Festplattenzuordnung anfänglich zusammenhängend sein kann und in diesem Fall für die Lebensdauer der VM zusammenhängend bleiben würde.

Mit BTRFS können Sie auch mit nodatacowund ähnlich Snapshots von Daten manuell mit CoWVerhalten erstellen , so dass es schnell ist und nicht viel Speicher verbraucht. Darüber hinaus sind diese Snapshots flexibler als die Verwendung von LVM, da Sie keinen Speicherplatz unter dem Dateisystem reservieren müssen, den das Dateisystem nicht kennt und der nicht verwendet werden kann, wenn er überhaupt nicht benötigt wird. Wie bei ZFS können Snapshots über das Netzwerk gesendet und empfangen werden, um Ihre Sicherungsstrategie zu verbessern. Selbst mit nodatacowBTRFS scheint die Verwendung von LVM überlegen zu sein.

Nachdem ich mit Cloud-Computing-Plattformen gearbeitet habe, habe ich ihre Sicht auf virtuelle Maschinen als Container für Daten und Funktionen übernommen, bei denen die tatsächliche VM von geringerer Bedeutung ist.

Ich möchte lieber gute Backup-Restore- und Install-Deployment-Prozesse einrichten und mich weniger um die Integrität der VM als vielmehr um die Leistung kümmern.

Das heißt, Sie entscheiden sich für JFS / XFS / EXT4 über LVM über MD-Raid und nicht für BTRFS. Stellen Sie sicher, dass ich niemals etwas speichere, das nicht für einen längeren Zeitraum auf der VM gesichert wurde ... und über Skripte und Verfahren verfügt, um eine Neuinstallation der VM innerhalb einer angemessenen Zeit zu sichern, falls etwas passieren sollte.

Dies ist jedoch mehr ein Entwicklungs- / Experimentierszenario als alles andere.