btrfs gesamter Platz wird weniger?

[scientific]

Hi.

Kann sich das jemand erklären? Ich blicke noch nicht ganz durch bei der Ausgabe von btrfs filesystem df

Ich habe folgendes Ergebnis

Code: Alles auswählen

# btrfs fi df .
Data, single: total=436.12GiB, used=386.14GiB
System, single: total=32.00MiB, used=96.00KiB
Metadata, single: total=8.00GiB, used=4.02GiB
GlobalReserve, single: total=512.00MiB, used=84.36MiB

Dann habe ich einige Runden balance laufen lassen mit aufsteigenden Parametern.

Code: Alles auswählen

(1 ✗ ) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=5 /
Done, had to relocate 1 out of 450 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=5 .
Done, had to relocate 0 out of 449 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=5 .
Done, had to relocate 0 out of 449 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=0 .
Done, had to relocate 0 out of 449 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=10 .
Done, had to relocate 0 out of 449 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=15 .
Done, had to relocate 0 out of 449 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:37) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=25 .
Done, had to relocate 6 out of 449 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:38) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -musage=25 .
Done, had to relocate 1 out of 443 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:38) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -musage=35 .
Done, had to relocate 2 out of 443 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:39) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -dusage=35 .
Done, had to relocate 6 out of 442 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:41) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -musage=5 .
Done, had to relocate 1 out of 436 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:42) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -musage=15 .
Done, had to relocate 1 out of 436 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:42) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -musage=25 .
Done, had to relocate 1 out of 436 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:42) /var/cache/btrfs_pool_SYSTEM: # btrfs balance start -musage=35 .
Done, had to relocate 2 out of 436 chunks
(0 ✓) SCREEN root@aldebaran[/@debian-testing] (18:43) /var/cache/btrfs_pool_SYSTEM: # btrfs fi df .

Und dann wollte ich wissen, wieviel Speicherplatz freigegeben wurde dadurch:

Code: Alles auswählen

 # btrfs fi df .
Data, single: total=423.12GiB, used=359.55GiB
System, single: total=32.00MiB, used=96.00KiB
Metadata, single: total=6.00GiB, used=3.25GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

"Data, used=" ist weniger geworden. Das habe ich auch erwartet.
Aber warum ist "Data, total=" auch weniger geworden? Gleich um 13 GB??? Ich habe in der Zwischenzeit nichts anderes gemacht.

lg scientific

[smutbert]

Oje, ich hab mir das folgendermaßen zusammengereimt, auch mit Hilfe des für mich etwas befremdlichen Verhaltens von fstrim, allerdings ohne, dass ich diese Vermutung irgendwie belegen könnte:
btrfs weist den Speichereinheiten (Chunks?) je nach Bedarf der Verwendung für Daten oder Metadaten zu. Übrig bleiben nicht verwendete Speicherbereiche, die in der Ausgabe nicht auftauchen. Im Betrieb mit den Schreibzugriffen und mit COW wird dann weiterer Speicher gebraucht und zugeordnet, andere Speichereinheiten, deren Inhalt eigentlich gar nicht mehr gebraucht wird, bleiben aber zugewiesen.
Durch das Umordnen mit balance werden nicht mehr benötigte Speichereinheiten sozusagen aufgegeben und verschwinden aus der Ausgabe.

Allerdings versteh ich nicht viel von Dateisystemen und weiß nicht ob meine Überlegungen überhaupt einen Sinn ergeben

[Profbunny]

Schau mal in die ausgabe von btrfs fi show oder btrfs fi usage das zeigt auch allokierte Bereiche mit an, evtl siehst du da ob sich was verschiebt.
Generell in das in Btrfs ziemlich kompliziert wie ich finde.

Bei meinen Recherchen bin ich mal über https://github.com/kdave/btrfsmaintenance/ gestolpert, allerdings schien mir eine Ausführung von balance
per cron nicht so recht nötig. Machst du das periodisch?

Wenn ich das richtig verstanden habe, schreibt er bei balance alle daten neu biin mir aber unschlüssig ob das auf meiner ssd gut kommt.

[scientific]

Nun, ich schreibe stündlich einen Snapshot, und lösche den ältesten damit auch gleich wieder.
Damit würde der Platz dann relativ rasch knapp werden.

Insoferne lasse ich wöchentlich ein balance mit -dusage=5 laufen. Auch -musage=5 ist mit dabei. Das schreibt mir so 1-2 Chunks regelmäßig neu. Das hält eine SSD aus. Wie war das nochmal, 30 GB täglich neu schreiben, über 100.000 Jahre ist das garantierte Schreiblimit gängiger SSDs... Da hab ich noch Spielraum

Ich glaub, einen wirklichen Wert, wieviel noch frei ist, kriegt man aus der Differenz von df (das normale, die Partitionsgröße) mit total von btrfs fi df.

Regelmäßiges balance und scrub ist bei btrfs schon angesagt - ergaben meine Recherchen.

[scientific]

Die maintenance-Skripte sehen wohlüberlegt aus.
Werd die mal genauer studieren. Da fehlt mir noch die Flexibilität für gelegentlich eingesteckte externe Datenträger, wohin ich die Backups schreibe.

[Profbunny]

Regelmäßiges balance und scrub ist bei btrfs schon angesagt - ergaben meine Recherchen.

hm, soweit ich gelesen habe, ist balance eigentlich für raids vorgesehen, im wiki steht zumindest nichts, dass es regelmäßig, auch ohne raid, ausgeführt werden sollte.
kannst ja mal von deinen erfahrungen mit den maintance scripten berichten.

[scientific]

Ich hab schon eine Erfahrung.
Beim Übertragen auf eine externe Platte verschluckte sich das Dateisystem gelegentlich und wurde unbenutzbar (am Zielsystem, einfache HDD).
Fsck zerstörte es jeweils ganz. Löschen von Snapshots führten zu einem Kernelfehler.
Balance auf diesem Datenträger behob dies. Dann lief auch scrub wieder durch.