unverständnis über ausgabe von df

[MSfree]

btrfs ist meiner Meinung nach immer noch nicht so robust wie ext3/4. In Produktivumgebungen würde ich es jedenfalls nicht einsetzen wollen.

Vor wie vielen Jahren hast du dir diese Meinung gebildet und wann hast du vor die anhand welcher Kriterien neu zu überdenken?

Meine Meinung wurde erst am letzten Samstag wieder bestätigt.

Ich habe Bookworm auf einem alten EeePC, der wegen seiner winzigen 4GB SSD sinnvoll nur mit einem komprimierenden Dateisystem einsetzbar ist. Das einzige unter Debian während der Installation auswählbare Dateisystem, das Kompression erlaubt, ist leider btrfs.

Wenn ich nach einem

Code: Alles auswählen

apt-get update
apt-get dist-upgrade
df
apt-get clean
df

für das zweite "df" die selbe Ausgabe erhalte wie nach dem ersten "df", dann ist das Filesystem für mich fragwürdig, weil apt-get clean im Schnitt um die 70MB freigibt. OK, bei dem EeePC kommt es mir nicht auf absolute Stabilität an, das Teil ist eher ein Proof-of-Konzept, das so alte Hardware überhaupt noch mit Debian läuft und eine Selbstzerstörung des Daeisystems wäre in diesem Fall völlig egal.

Die Foren sind auch voll davon, daß btrfs keine brauchbare Aussage liefert, wieviel Platz nun verbraucht bzw. noch frei ist. Das wird dann auch immer breit und episch von den Entwicklern verteidigt. Für mich ist das ein KO-Kriterium. Ein Dateisystem, das nichtmal die einfachsten Infos liefern kann, will ich nicht in einem Produktivsystem.

[wanne]

Das einzige unter Debian während der Installation auswählbare Dateisystem, das Kompression erlaubt, ist leider btrfs.
[…]
für das zweite "df" die selbe Ausgabe erhalte wie nach dem ersten "df", dann ist das Filesystem für mich fragwürdig, weil apt-get clean im Schnitt um die 70MB freigibt.
[…]
Das wird dann auch immer breit und episch von den Entwicklern verteidigt. Für mich ist das ein KO-Kriterium. Ein Dateisystem, das nichtmal die einfachsten Infos liefern kann, will ich nicht in einem Produktivsystem.

Das eine hängt halt mit dem anderen zusammen.
Wenn du ausschließlich redundante Informationen löschst, dann ist es nicht verwunderlich, dass sich nach der Kompression sich an der Belegung wenig bis nichts geändert hat. Bei jedem Dateisystem das vernünftige Deduplication/Kompresssion/Snapshots/Subvolumes hat, speichert wird nunmal die Eigenschaft haben, dass gelöschte Datenmenge komprimierte Daten keinen einfachen Zusammenhang mehr haben. Genau das ist die Idee von diesen Features, dass man Platz spart und es ist zwangsläufig entsprechend rückwärts läuft das natürlich auch wieder beim Löschen.
Man kann jetzt als Nutzer zu dämlich sein das zu kapieren. Aber ein Problem vom Dateisystem ist das ganz sicher nicht. Nutze die entsprechenden Features nicht, und es gibt auch wieder einen einfachen Zusammenhang zwischen belegtem Platz und Dateien.

[MSfree]

Wenn du ausschließlich redundante Informationen löschst, dann ist es nicht verwunderlich, dass sich nach der Kompression sich an der Belegung wenig bis nichts geändert hat.

Wenn ich etwa 70 Pakete im oben genannten Szenario zu aktualisieren habe, handelt es sich nicht um "auschlie0lich redundante" Informationen. Debianpakete selbst sind bereits komprimiert, lassen sich also durch die tranparente Dateisystemkompression nicht weiter eindampfen. Die belegen erstmal Platz. Erst mit dem clean werden die runtergeladenen Pakete gelöscht und die Hilfsdateien, die apt nutzt, entfernt.

Dabei muß zwnagsläufig Platz wieder freiwerden, weil es insgesamt nur extrem wenig gibt, das überhaupt dedupliziert werden könnte. Mir ist natürlich klar, daß die rund 70MB Hilfsdateien, die apt unter /var/cache/apt erzeugt, komprimiert deutlich weniger als 70MB im Dateisystem benötigen, aber gar keine Änderung darf es halt auch nicht geben.

[wanne]

Wenn ich etwa 70 Pakete im oben genannten Szenario zu aktualisieren habe, handelt es sich nicht um "auschlie0lich redundante" Informationen.

Doch. Die Daten die unter /var/cache/apt cache liegen sind selbstverständlich nochmal irgend wo. Im Paket /var/cache/apt/archies/xterm_344-1+deb10u1_amd64.deb hängt z.B. die selbe Binary, die nochmal unter /usr/bin/xterm hängt. Nur da halt unkomprimiert. Der für dich relevantere Teil dürfte sein: Vermutlich liegt das selbe Paket nochmal auf irgend einem anderen Subvolume/Snapshot.

Die belegen erstmal Platz.

Offensichtlich nicht. Ob du das glauben magst oder nicht.

Mir ist natürlich klar, daß die rund 70MB Hilfsdateien, die apt unter /var/cache/apt erzeugt, komprimiert deutlich weniger als 70MB im Dateisystem benötigen, aber gar keine Änderung darf es halt auch nicht geben.

Wenns dumm läuft braucht es nach dem Löschen sogar mehr platz. Das ist halt das was du dir einhandelst, wenn du Ressource-Sharing über mehrere Dateien hast. Btw. kann dir ähnliches auch bei ext4 passieren. Löschst du Dateien unter 4kiB wird oft auch nicht mehr Platz frei, weil sich diese Dateien den Platz mit den Metadaten teilen und ext4 in 4k Blöcken arbeitet und den Rest bis zum vollen 4k-Block immer mit "Müll" füllt. Schon bei ext2 hast du einen ähnlichen Effekt, wenn du von einer Datei weniger als 4kiB abschneidest wird eventuell kein Einziges Byte frei. Dach deiner Definition sind also auch all diese Dateisysteme kaputt. Bleibt FAT mit 1Byte Blöcken als das einzig wahre Dateisystem.
Beispeil ext4:

Code: Alles auswählen

du -sh /usr/bin/xxd 
20K     /usr/bin/xxd
ls -lh /usr/bin/xxd 
-rwxr-xr-x 1 root root 19K Jun 15  2019 /usr/bin/xxd

Eigentlich ist sie nur 19kiB groß. Aber ext4 rundet immer auf volle 4kiB auf. Eigentlich sollte du jetzt bei btrfs (dank kompression) weniger anzeigen. Leider geht das ganze bei btrfs nicht mehr auf, weil eben mehrere Dateien die gleichen Daten nutzen können und so nicht mehr eindeutig ist, welcher Block zu welcher Datei gehört. Hast du 2 8kiB große Dateien, die beide die selbeben ersten 4kiB nutzen brauchen die beide 12kiB. btrfs reportet dann aber für beide 8kiB. – Was zusammen 16kiB gäbe würde es für beide 4kiB reporten käme aber halt auch das falsche raus... – Und für 2 gleich große Dateien ein mal 4kiB und ein mal 8kiB wäre absolut quatschig.

[MSfree]

Im Paket /var/cache/apt/archies/xterm_344-1+deb10u1_amd64.deb hängt z.B. die selbe Binary, die nochmal unter /usr/bin/xterm hängt. Nur da halt unkomprimiert.

Die beiden werden sich aber nie und nimmer irgendwelche Resourcen teilen. Das, was im .deb ist, ist komprimiert und dadurch eine völlig andere Folge von Bytes, wie das Binary unter /usr/bin. Keinerlei Ähnlichkeit = keinerlei Resource-Sharing.

Davon abgesehen, du schreibst hier, daß ZFS Deduplikation bescherrscht, ich gehe mal davon aus, das btrfs das nicht kann. Ich rede hier aber über btrfs, solches Resourcesharing dürfte es also unter btrfs gar ncht geben.

[Meillo]

df gibt doch an, wie viel Platz auf dem Dateisystem (dem User) zur Verfuegung steht.

Falls das Dateisystem intern irgendwelche Bloecke aus irgendeinem Grund weiterhin belegt, dann muss ein Loeschen von Dateien durch den User nicht zwangslaeufig zu mehr freiem Speicher fuehren. Selbst wenn keine Deduplikation oder Snapshots im Spiel sind kann das Dateisystem intern ja irgendwelche seltsamen Dinge machen (Bitcoins minen, Sudokus loesen, Pi berechnen, oder so). ... vielleicht muss man erst mal die Garbage-Collection von btrfs anwerfen damit der Speicher frei wird.

[wanne]

Davon abgesehen, du schreibst hier, daß ZFS Deduplikation bescherrscht, ich gehe mal davon aus, das btrfs das nicht kann.

Btrfs kann keine on the fly deduplication: Also du schreibst eine Datei – es sucht automatisch ob es nochmal irgend wo die selbe gibt. Man kann ihm aber (z.B. beim kopieren) durchaus Hints geben und es lieferte ein Programm mit, dass doppelte Daten sucht und die dann explizit zusammenfasst.

Das, was im .deb ist, ist komprimiert und dadurch eine völlig andere Folge von Bytes, wie das Binary unter /usr/bin. Keinerlei Ähnlichkeit = keinerlei Resource-Sharing.

Code: Alles auswählen

$ tar caf Elarun.tar.xz /usr/share/wallpapers/Elarun/
$ tar caf both.tar.xz /usr/share/wallpapers/Elarun/ kde-wallpapers-default_4%3a15.04.2-1_all.deb
$ ls -lh both.tar.xz Elarun.tar.xz kde-wallpapers-default_4%3a15.04.2-1_all.deb 
-rw-r--r-- 1 wanne wanne 1.7M Oct 12 16:03 both.tar.xz
-rw-r--r-- 1 wanne wanne 1.6M Oct 12 15:59 Elarun.tar.xz
-rw-r--r-- 1 wanne wanne 1.6M Sep  8  2015 kde-wallpapers-default_4%3a15.04.2-1_all.deb

Funktioniert wohl doch ganz gut.. Oops...