btrfs - Ist es gefährlich, Subvolumes zu defragmentieren, die schreibgeschützte Schnappschüsse enthalten?

Wenn Sie den defragmentAbschnitt von öffnen btrfs-filesystem(8), sehen Sie die folgende bedrohliche Inschrift, die von den Entwicklern hinterlassen wurde:

Warnung: Durch die Defragmentierung mit Linux-Kernelversionen <3.9 oder ≥ 3.14-rc2 sowie mit stabilen Linux-Kernelversionen ≥ 3.10.31, ≥ 3.12.12 oder ≥ 3.13.4 werden die Ref-Links von COW-Daten (z. B. Dateien) aufgelöst kopiert mit cp --reflink, Schnappschüssen oder de-duplizierten Daten). Dies kann in Abhängigkeit von den unterbrochenen Ref-Links zu einer erheblichen Erhöhung der Speicherplatznutzung führen.

Das hört sich schrecklich an. Ein Verkaufsargument btrfsist die Fähigkeit, Schnappschüsse zu erstellen, ohne alles zu kopieren. Ich erstelle meistens schreibgeschützte Schnappschüsse.

Zählen die Dateien mit schreibgeschützten Snapshots auch als "COW-Daten" oder überlebt die Deduplizierung des übergeordneten Subvolumes, ohne dass der Speicherplatz aufgebläht wird?

Ja, Dateien in einem schreibgeschützten Snapshot gelten als COW-Daten und tragen dazu bei, dass der Speicherplatz durch Defragmentierung aufgebläht wird.

Wenn eine Defragmentierung auftritt, werden Daten aus den alten Extents in weniger neue Extents kopiert. Die neuen Ausmaße unterscheiden sich von den alten Ausdehnungen. Alle anderen Kopien der Datei (z. B. in Schnappschüssen) verweisen weiterhin auf die alten Speicherbereiche. Daher haben Sie Daten aufgebläht.

Es gibt einen langen Thread über die Defragmentierung auf der Mailingliste, der hier beginnt und einige interessante Punkte enthält.

Btrfs defragmentiert nicht alle Reflinks

Nur die besonderen Fälle, auf die Sie hinweisen. Also, wenn Sie Subvolume haben A, und Schnappschüsse S1und S2dieser Subvolume A, dann läuft defrag auf nur Subvolume Awird die Reflinks zwischen ihm und den Schnappschüssen brechen, aber S1und S2teilen sich nach wie vor alle Daten , die sie miteinander ursprünglich waren. Wenn Sie dann einen dritten Schnappschuss von machen A, werden Daten mit A, aber nicht mit S1oder geteilt S2(weil Akeine Daten mehr mit S1oder geteilt werden S2).

Angesichts dieses Verhaltens haben Sie wiederum drei mögliche Fälle, wenn Sie über dauerhafte Schnappschüsse sprechen:

1. Sie legen Wert auf die Minimierung des Speicherplatzbedarfs , sind jedoch nicht so besorgt über die Leistung.
   In diesem Fall besteht die einzige Möglichkeit darin, die Defragmentierung überhaupt nicht auszuführen .
2. Sie legen Wert auf Leistung , aber nicht auf Speicherplatznutzung. In diesem Fall defragmentieren Sie alles .
3. Sie legen Wert auf Speicherplatznutzung und Leistung. In diesem ausgewogenen Fall würde ich persönlich vorschlagen, nur das Quell-Subvolumen (also nur das Subvolumen Ain der obigen Erklärung) zu defragmentieren und dies nach einem Zeitplan zu tun, der mit der Rotation des Schnappschusses zusammenfällt. Die Idee ist, defragmentkurz bevor Sie einen Schnappschuss machen, und zwar mit einer Häufigkeit, die ein ausgewogenes Verhältnis zwischen Speicherplatznutzung und Leistung bietet. Wenn Sie diese Route wählen, beginnen Sie in der Regel damit, die Defragmentierung entweder monatlich durchzuführen, wenn Sie tägliche oder wöchentliche Schnappschüsse erstellen, oder, falls nicht, mit jedem vierten Schnappschuss, und passen Sie dann das Intervall an, je nachdem, wie sich dies auf Ihre auswirkt Raumnutzung.

Quelle: Btrfs-Mailingliste , auf die von Spacedog verwiesen wird.

Btrfs Defragmentierung schreibgeschützt Schnappschuss

Aufgrund meiner Erfahrung mit Versuchen und Fehlern führte das Defragmentieren von Snapshots von btrfs (um die neue zstd-Komprimierung zu verwenden) zu 100% Exklusivität und 0,00 Byte gemeinsam genutzter Daten.

Vorher btrfs defragment:

# btrfs filesystem du -s /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/
     Total   Exclusive  Set shared  Filename
   1.41GiB     6.27MiB     1.41GiB  /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/

Nachher btrfs defragment:

# btrfs filesystem du -s /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/
     Total   Exclusive  Set shared  Filename
   1.42GiB     1.42GiB       0.00B  /mnt/btrfs/Backups.backupdb/d2/readonly-snapshot/

Freigegebene Daten gehen auf 0,00B zurück