[BTRFS] Komprimierung und Subvol aus Verzeichnis

[Lookbehind]

Hallo zusammen,

ich hab hier ein System (Buster, 4.19.0-10) mit btrfs seit einiger Zeit im Einsatz und bin soweit zufrieden damit. Allerdings gibt es ja immer mal Dinge, die man noch optimieren möchte. Aktuell schweben mir 2 Dinge vor, bei denen ich gerne euren Rat hätte.

1. Kompression.
Btrfs kann transparente Kompression auf Dateisystem-Ebene. Hab ich nie ausprobiert, würde ich aber, zumindest für das Subvolume mit dem Daten-Grab mal testen wollen. Wenn ich das Wiki dazu lese, klingt das so, als wäre lzo das sinnvollste, weil zlib wohl zu langsam ist (der Rechner hat nicht all zu viel Bums unter der Haube) und zstd wohl nur mit neuen Kerneln funktioniert und das Probleme in einem Rescue-Scenario verursachen könnte.
Da ich, aus Angst vor Leistungseinbußen, nicht das komplette Dateisystem komprimieren wollen würde, wäre chattr mein Werkzeug.

Code: Alles auswählen

chattr +c /btrfsroot/subvol/datengrab

Bloß wie gebe ich den Kompressions-Algorithmus an? Und wie sind überhaupt die Erfahrungen mit komprimierten Daten auf btrfs? Tipps und Fallstricke auf die ich achten sollte?
(Ja, mir ist klar, dass ohne ein defrag nur neu geschriebene Daten komprimiert werden, und auch nur, wenn die Daten zum komprimieren lohnen.)

2. Ein SubVolume aus einem Verzeichnis machen.
Leider habe ich bei der Aufteilung der Subvolumes einen Fehler gemacht. Das Subvol /btrfsroot/subvol/datengrab gibt es noch nicht, und ist noch Bestandteil von /btrfsroot/subvol/home. Was leider auch bedeutet, dass ich das Datengrab in einigen Snapshots unnötigerweise mit drin habe. Ich würde gerne aus dem Unterverzeichnis Datengrab ein eigenes Subvolume machen, bin mir aber unschlüssig was die beste Methode ist. Normalerweise würde man ein neues Subvolume erstellen, dann die Daten rüber kopieren und um mounten.

Code: Alles auswählen

btrfs subvol create /btrfsroot/subvol/datengrab
cp -ar /home/Datengrab /btrfsroot/subvol/datengrab
mount /dev/sda4 -o subvol=/btrfsroot/subvol/datengrab /home/Datengrab
vim /etc/fstab

Dafür reicht aber der Platz auf dem Datenträger vermutlich nicht aus. Außerdem dürfte das ziemlich lange dauern.
Da dachte ich mir: Gibts da nicht was von btrfs? Was, wenn ich einfach einen Snapshot von dem original Subvol erstelle und dann nur die nicht benötigten Daten raus lösche?

Code: Alles auswählen

btrfs subvol snapshot /btrfsroot/subvol/home /btrfsroot/subvol/datengrab
rm -rf /btrfsroot/subvol/datengrab/user
mv /btrfsroot/subvol/datengrab/Datengrab/ /btrfsroot/subvol/datengrab
mount /dev/sda4 -o subvol=/btrfsroot/subvol/datengrab /home/Datengrab
vim /etc/fstab

Aber welche Implikationen hat das? Weil es ja ein Snapshot ist. Ich habe die Erfahrung gemacht, das btrfs mit zu vielen Snapshots sehr langsam wird, und so erstelle ich gerade einen Snapshot, den ich nie wieder löschen kann. Oder löst sich das Verhältnis, wenn irgendwann keine gemeinsamen Daten mehr in den beiden Subvols liegen? Gibt es sonstige Implikationen bei der Vorgehensweise?

Oder mach ich mir die Sache wieder viel zu kompliziert und das geht eigentlich ganz einfach? Wenn ja, wie?

TIA

Look

[smutbert]

Bei einem Punkt kann ich aus dem Stehgreif helfen:
Wenn du mit der Option --reflink=always innerhalb eines Dateisystems kopierst, zB von einem Subvolume auf ein anderes, werden die Daten nicht tatsächlich kopiert. Also subvolume anlegen, Daten mit

Code: Alles auswählen

cp -a --reflink=always irgendwas/altes_datengrab irgendwas/datengrab_als_eigenes_subvolume

kopieren und hinterher die Originaldaten löschen.

In dem Fall spielt es imho keine Rolle ob das subvolume leer angelegt oder als Snapshot erzeug wird. Dein Weg macht im Endeffekt dasselbe wie mein Vorschlag und ich sehe da auch performancemäßig keinen Nachteil – es geht um einen Snapshot, der ja sowieso zu einem von den Daten her komplett eigenständigen Subvolume wird, weil du die Originaldaten löscht. Logisch bleibt die Information wohl erhalten, dass das eine Subvolume vom anderen abstammt, aber es hat keine weiteren Auswirkungen von denen ich wüsste.
In beiden Fällen hat man halt vorübergehend „deduplizierte“ Daten, einmal durch den Snapshot und in meiner Variante durch das --reflink


Ich habe die Kompression bis jetzt nur auf langsamen Datenträgern genutzt, zum Beispiel auf Debianinstallationen auf USB-Sticks und ist die Kompression performancemäßig ein Vorteil, fast egal wie langsam die CPU ist.
Ich habe aber keine Idee ob/wie man den zu verwendenden Kompressionsalgorithmus bestimmten könnte, wenn man nicht das ganze Dateisystem komprimieren will.

[Lookbehind]

Tja, zu spät.

Ich hab gleich zwei Fehler gemacht.
1. Mein Test-System entsprach nicht dem Live-System. Ich hab mich einer anderen Möglichkeit entsonnen, die ja eigentlich viel logischer ist, nämlich mv. Ich will ja verschieben, und nicht kopieren. Also hab ich auf einem anderen System, bei dem es nicht so drauf an kam, gerade ein Test-Setup gemacht und ~250GB aus einem Verezeichnis in ein neues Subvolume verschoben. Das war in weniger als 2 Sekunden fertig. Super! Dann kann man das ja mit dem produktiv-System genauso machen. ... bloß das mein Test-System mit Testing und Kernel 5.8.0-1 läuft, statt Buster und 4.19.0-10 wie das Produktiv-System. ... da ging das nicht so schnell. Der mv Vorgang ist jetzt schon seit knapp 2h zugange und ich trau mich nicht das ab zu brechen. Da das Verzeichnis aber Live eingehängt ist ... ach ich will nicht drüber nachdenken.
2. Notiz an mich selbst: Wenn du ein System einrichtest, welches Snapshots ermöglicht, und du vor hast, auf diesem System Operationen aus zu führen, die evtl schief gehen könnten, DANN MACH GEFÄLLIGST VORHER EINEN SNAPSHOT DU IDIOT!

Die Frage nach der Kompression bleibt allerdings. Die Datenträger auf denen ich das anwenden würde sind nebenbei auch drehender Rost (5400rpm)

[smutbert]

ich weiß noch nicht ob das bei Verzeichnissen auf (neu angelegten) Inhalt vererbt wird, aber es geht zumindest bei einzelnen Dateien

Code: Alles auswählen

# touch testfile
# btrfs property set testfile compression zstd
# btrfs property get testfile
compression=zstd

[Lookbehind]

Laut Manpage wird es vererbt, aber nur für neue Dateien.

Can I set compression per-subvolume?

Currently no, this is planned. You can simulate this by enabling compression on the subvolume directory and the files/directories will inherit the compression flag.

https://btrfs.wiki.kernel.org/index.php ... bvolume.3F

Ich habs jetzt auf dem Test-System (aka mein Desktop, Debian-Testing, 5.8.0-1, SSDs) mal ausprobiert:

Code: Alles auswählen

# mount /dev/sda1 /btrfsroot/
# cd /btrfsroot/
# btrfs property set storage/home compression zstd
# btrfs property get /home
ro=false
label=data
compression=zstd
# lsattr -d /home
--------c----------- /home
# btrfs property get snaps/storage/home_20200920_194853/
ro=true
# lsattr -d snaps/storage/home_20200920_194853/
-------------------- snaps/storage/home_20200920_194853/

btrfs property set setzt also auch das c-Attrib auf das Verzeichnis. Werde mal beobachten, wie sich das jetzt verhält und das dann gegebenenfalls auch auf das Datengrab auf der anderen Kiste anwenden.

... der ist übrigens immernoch dabei da alles durch die Gegend zu moven. Wenn meine Hochrechnung stimmt, ist er Dienstag Abend damit fertig. Ich hoffe es geht schneller.
Ich glaube das Problem ist dabei weniger die Größe, sondern die schiere Anzahl der Dateien. Er wird vermutlich gerade alle Dateisystem-Einträge für alle diese Dateien neu anlegen.

[Lookbehind]

Gegeben den kleinen Fehler mit der sehr zeitaufwändigen Auswirkung vom letzten Wochenende, kam mir in den Sinn, ob das Problem nicht evtl deutlich kleiner ausgefallen wäre, wenn da SSDs mit im Pool gesessen hätten, und nicht nur drehender Rost.
Ich meine, ich hätte auf dem System noch 2 SATA m.2 Slots, da könnte man was rein stecken. Muss ja nicht groß sein, wäre ja in erster Linie für die Metadaten.

Darum mal die Frage: Gibt es Erfahrungen mit BTRFS-Pools die sowohl aus klassischen HDDs sowie aus SSDs bestehen? Also gemischt in einem Pool?

[smutbert]

Wenn ein Dateisystem mehrere Geräte umfasst, kannst du für Daten und Metadaten getrennt bestimmen wie btrfs damit umgeht. Du könntest zB die Daten ganz normal einmal speichern (single) und die Metadaten auf zwei der Geräte spiegeln (raid1). Aber ganz egal was du machst btrfs selbst geht mit allen Geräten gleich um und berücksichtige nicht, dass manche Geräte schneller sind als andere und du kannst auch nicht enscheiden welche Daten oder Metadaten wo landen.

Vielleicht bietet der device-mapper eine Schicht darunter eine Möglichkeit mehrere Geräte zu einem Blockgerät mit einem schnelleren als Cache zusammenzufassen oder ähnliches (ich glaube lvm kann das), davon weiß dann aber btrfs nichts und es weiß dann auch nicht, dass es auf mehrere Datenträger verteilt ist.

[Lookbehind]

Kurz: Außer der Speichererweiterung hätte ich nix davon. ... vergebene Chance. Schade.