Seiten: [1] 
|
 |
|
|
Autor
|
Thema: Ein COW Dateisystem erfodert umdenken (Gelesen 214 mal)
|
|
Sebastian
YaBB God
 Offline
Einträge: 584
|
 |
Ein COW Dateisystem erfodert umdenken
« am: 07. Januar 2025, 18:31:34 »
|
|
Hallo Suletuxe,
Ich hatte gestern folgende Situation gehabt. Ich wollte etwas an einer ca. 6 GB großen ISO Datei ausprobieren. Und zwar wollte ich diese mit xorriso bearbeiten. Um nicht die Original ISO Datei zu verlieren, habe ich xorriso angewiesen die Änderungen in eine neue ISO Datei zu speichern. Was dazu führte, dass noch einmal 6 GB Daten + meinen Veränderungen auf die Festplatte geschrieben wurde. Das wiederum natürlich auch etwas dauerte.
Bei der nächsten Änderung von der Original ISO habe ich mir die COW (Copy on Write) Fähigkeit meines Dateisystems zur nutze gemacht. Ich habe im Vorfeld von der Originaldatei eine referenzierte Kopie erstellt. Dies war in weniger als einer Sekunde erledigt, da hier nur die Metadaten im Dateisystem geändert werden mussten, und die Kopie belegte somit auch keinen zusätzlichen Speicherplatz auf meiner Festplatte (dies schonte die SSD). Dieses Mal habe ich xorriso angewiesen direkt die Kopie der ISO zu bearbeiten, das dieses mal auch in Sekunden erledigt war, weil nur noch die Änderungen geschrieben werden mussten. Was ein weiteres mal die SSD geschont hat und somit statt mehreren GB an Daten nur noch ein paar KB geschrieben werden mussten. Natürlich haben dadurch auch nur die paar KB an Änderungen Speicherplatz auf meiner Festplatte mehr verbraucht.
Mt ext4 hätte ich dies nicht tun können, hier wäre ich wie bei meinem ersten Versuch gezwungen gewesen, die ganze Datei noch einmal neu zu schreiben, wenn ich eine Sicherungskopie der Originaldatei behalten möchte. Oder ich hätte ohne Netz direkt die Original ISO Datei bearbeiten müssen.
Für die Arbeitsweise, also die Dinge, die ich an meinem Computer mache, ist Btrfs ein richtiger Glücksgriff für mich gewesen. Da ich vom COW sehr häufig profitieren kann. Man muss sich nur auch erst einmal an die neuen Möglichkeiten gewöhnen, die manchmal ein Umdenken, Umgewöhnung erfordern.
Somit sollte ich beim anlegen von Dateien oder Verzeichnissen auch darüber Nachdenken ob diese von COW überhaupt proftieren oder ob es da eher von Nachteil wäre. Somit schlate ich bei Festplatten Images von VMs die COW Funktion von Btrfs aus. Da diese durch die viele zufälligen Schreibvorgänge stark fragmentieren würden. Was wiederum dazu führen würde das mein Dateisystem unnötig Speicherplatz allokieren würde. Also auch bei SSDs wird es da interessant. Dann könnte man auch noch in Verzeichnissen wodrin viele neue kleine Dateien entstehen können z.B. wo Software gebaut/compiliert wird COW ausschalten, damit das Dateisystem hier schneller reagiert.
Und keine Angst, wenn ein Snapshot eines Subvolumen angelegt wird, wodrin sich Dateien und Verzeichnisse befinden, wo COW deaktiviert ist. Auch diese werden gesnaptshotet. Dies wird erreicht, indem COW für diese Dateien für den Snapshot kurz automatisch wieder eingeschaltet wird. So das eine Intakte Kopie im Snapshot entsteht.
Aber Vorsicht, Dateien wo COW deaktiviert wurde, für diese werden keine Prüfsummen von Dateisystem erstellt. Diese können vom Dateisystem also nicht auf Validität geprüft werden. Und man muss einfach darauf hoffen wie bei anderen Dateisystemen das hier noch alles in Ordnung ist und nichts über die Zeit kaputtgegangen ist. Damit können diese auch nicht von Selbstheilung und co. profitieren.
Bei mir sind dies aber zum Glück alles Daten, die leicht wieder neu erstellt werden können oder nicht so wichtig sind. Ansonsten hilft da wie immer ein Backup zu haben. 
LG
Sebastian
|
| « Letzte Änderung: 07. Januar 2025, 18:35:45 von Sebastian » |
 Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1408
Linux von Innen
|
|
Re:Ein COW Dateisystem erfodert umdenken
« Antwort #1 am: 08. Januar 2025, 07:02:00 »
|
|
Ein solches Dateisystem ist wärmstens zu empfehlen, wenn man experimentieren will und auch mal Dinge ausprobieren will, deren erfolgreicher Ausgang mehr als fraglich ist. Mit einem COW-Dateisystem hat man dadurch ein "Netz mit doppeltem Boden" und kann auch über fatale Fehler lächeln.
Im Produktivbetrieb versuche ich solche Dinge gerade zu vermeiden. Ich überlege stets bevor ich etwas mache, ob ich damit eventuell etwas zerstöre. Der gravierende Nachteil eines COW-Dateisystems ist die Größe des Datenträgers, wenn sich die Dateien schnell und umfangreich ändern. Ist ja auch logisch: woher sollen denn all die Wiederherstellungsmöglichkeiten kommen, wenn nicht alles irgendwo gesichert worden ist? Ein Arch-System wie meines, bei dem ich pro Woche 3...20GB an Updates herunterlade (die ja auch erstmal entpackt werden müssen um installiert zu werden) wächst mit einem COW-Dateisystem wie ein Krebsgeschwür. SSDs mit den benötigten Speichergrößen gibt es noch gar nicht, um solche Systeme über Jahre zu halten...
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 584
|
|
Re:Ein COW Dateisystem erfodert umdenken
« Antwort #2 am: 08. Januar 2025, 18:00:01 »
|
|
Wenn sich Dateien schnell und umfangreich ändern, wirkt sich COW eigentlich nur negativ auf die Geschwindigkeit des Dateisystems aus. weil zu jeder veränderten bzw. neuen Dateien zusätzlich Checksummen gebildet werden um Daten auf Validität später prüfen zu können. Das ist ein Sicherheitsmerkmal, das die meisten Dateisysteme nicht haben. Und Referenzen verfolgt werden müssen. Negativ auf dem Speicherplatz verbrauch schlagen solche Aktionen nur temporär auf. Denn zusätzlichen Speicherplatz muss nur vorgehalten werden, wenn Daten die gelöscht wurden, noch in einem Snapshot zur Verfügung stehen. Dieser Speicherplatz kann dann erst wieder freigeben werden, wenn nirgendwo im Dateisystem die zu löschenden Daten mehr referenziert/vorgehalten werden müssen.
Ansonsten, wenn Daten verändert werden und diese keine weitere Referenz z.b. durch einen Snapshot oder einen Reflink Kopie (Kann man sich vorstellen wie ein Snapshot auf ein paar Dateien beschränkt) besitzen. So wird im Nachgang, wenn die neue Datei mit den geänderten Daten im neuen Sektor angelegt wurde (und auf Gesundheit geprüft wurde) die alte Kopie der Datei vergessen, und damit wieder Speicherplatz freigeben.
In Wirklichkeit macht btrfs das auf Blockebene und nicht auf Dateiebene also filigraner, aber fürs bessere Verständnis spreche ich hier von Dateien.
Sind Dateien hingegen in einem Snapshot oder per Reflink Kopie vorhanden und werden diese im Nachgang geändert. So wird nicht extra viel mehr Speicherplatz verbraucht, sondern es tritt eher das Gegenteil ein. In diesem Fall weis Btrfs das Datei A noch in einem Snapshot vorhanden ist, und somit nur die Änderungen in einen neuen Sektor gespeichert und eine Referenz auf die alte Datei angelegt werden muss. So das die aktuelle Version der Datei dann aus der alten Version + den neuen Änderungen zusammengesetzt wird. Dies spart somit sogar mehr Speicherplatz ein als bei einem Dateisystem ohne COW. Was auf Dauer dann aber auf Kosten der Geschwindigkeit geht. Denn wenn ich jetzt 100 mal die Datei A immer wieder abändere und immer nur kleine Änderungen gespeichert und referenziert werden, so muss das Dateisystem die aktuelle Version von der Datei aus 100 Stücken zusammensetzten und die Referenzen verfolgen, was Zeit kostet. Deswegen der Tipp Verzeichnisse, indem sich häufig veränderte Dateien befinden kann man COW abschalten. Systemd z.b. macht das für sein Systemlog /Journal z.b. automatisch, da log Dateien, häufig geändert werden und von COW auch nicht profitieren.
Von komplett neuen Daten/Dateien müssen wir glaube ich nicht sprechen. Da verhält es sich so wie bei jedem anderen Dateisystem auch, neue Daten kosten Speicherplatz und werden in noch leeren Blöcke auf den Datenträger abgespeichert. Speicherplatz, verbrauch und Geschwindigkeit (bis auf den Overhead durch Checksummen, Bildung und eventuelle Komprimierung) bleibt das Verhalten zu anderen Dateisystemen ohne COW gleich.
Beispiel an einem pacman Update ohne vorhanden Snapshot:
- pacman lädt 20GB neue Daten in form von neuen Pakten herunter. 20 GB zusätzlicher Speicherplatz verbrauch
- pacman entpackt die Pakete und überschreibt dabei eventuell vorhanden Daten/Dateien Speicherplatz verbrauch nur für neue Daten, z.B. Datei ist gewachsen oder es sind welche dazu gekommen. alte Daten werden nach Gültigkeitsprüfung verworfen)
Beispiel an einem pacman Update wo vorher ein Snapshot vorhanden ist:
- pacman lädt 20GB neue Daten in form von neuen Pakten herunter. 20 GB zusätzlicher Speicherplatz verbrauch
- pacman entpackt die Pakete und überschreibt dabei eventuell vorhanden Daten/Dateien (Speicherplatz verbrauch nur für neue Daten, z.B. Datei ist gewachsen oder es sind welche dazu gekommen. Hier bilden nun die geänderten Dateien Referenzen auf die alte Version im Snapshot. Die aktuelle Version der Datei, wird somit aus mehren Referenzen zusammen gesetzt.
Wenn man das mit einer Buchhaltung vergleichen mag, wäre das Quasi so, als ob man anfängt ein Buch A zu lesen, und auf Seite zwei steht dann auf einmal weiter gehts im Buch B auf Seite 1.
Wären diese mechanismen nicht geben so hätte man sonst wirklich ganz schnell ein Speicherplatz Problem.
Um zu wissen wann Btrfs wirklich Speicherplatz wieder freigeben kann, so muss man auch wissen, das Dateien oder Teile einer Datei in einen sogenaten Extent abspeichert. Ein Extent ist eine Gruppe von Blöcken. Mal angenommen ein Extent ist 1 GB groß und dort drin befinden sich nun mehre Dateien. Wenn ich jetzt ein paar Dateien lösche, wird der Speicherplatz dieses Extent erst wieder freigeben, wenn dieser vollständig leer ist. Also sich keine Daten mehr drin befinden. Da dies auf dauer zu Speicherplatz Verschwendung führen würde, wenn ich 1 GB verliere nur weil sich da noch eine 1 MB große Datei drin aufhält, dafür gibt es dann btrfs balance das diese Extents neu packt und somit wieder Speicherplatz freigeben werden kann, indem die Dateien wieder in ein Extent verpackt werden. Und somit der Plaz besser genutzt wird.
Was ein COW Dateisystem auch gut beschreibt ist dieser Artikel hier:
https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/
Wovon folgende Bilder Stammen:
Dieses Bild zeigt die Arbeitsweise eines klassischen Dateisystems, das die Daten an Ort und stelle ersetzt.
Dies Bild zeigt hingegen ein COW Dateisystem wo Daten niemals überschrieben werden und alte nicht mehr Rferrenzierte Daten vergessen werden.
Oder wenn man die Echte Physikalisch Position ausser acht lässt, würde das in etwa so aussehen. Man erkennt auch hier das nicht mehr Referenzierte Blöcke wieder freigeben werden, aber niemal etwas überschrieben wird.
Hier werden farblich Snapshots dargestellt. Man erkennt das kein zusätzlicher Speicherplatz verbrauch entsteht, es aber auch kein Speicherplatz freigeben wird, solange die Daten noch durch einen Snapshot referenziert werden.
Das ist auch der Grund, warum ich Snapshots auch nicht für die Ewigkeit aufbewahre und diese durch Routieren lasse. Damit nach einer gewissen Zeit auch Speicherplatz wieder freigegeben werden kann.
Edit:
PS:
Genau diese Sicherheitsnetze ob Snaphots, VMs und Ko. Erlauben es mir einfach drauflos zu probieren. Denn auch aus Fehlern kann man lernen. Und da jetzt Fehler keine Konsequenzen mehr haben, ist man viel eher dazu bereit einfach neue Dinge auszuprobieren, zu erforschen und dadurch etwas zu lernen.
LG
Sebastian
|
| « Letzte Änderung: 08. Januar 2025, 18:39:35 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Sebastian
YaBB God
Offline
Einträge: 584
|
|
Speicherplatz mit COW Sinvoll nutzen.
« Antwort #3 am: 10. Januar 2025, 19:19:07 »
|
|
Hallo Suletuxe,
Ich habe ja schon woanders erwähnt, dass ich seid dem ich mit Btrfs gestartet bin ca. mit 80 GB Daten (Root + home) begonnen habe. Da ich eine 1 TB große Festplatte besitze und der rest der Platte die meiste Zeit nur ungenutzt brach liegt, wollte ich diesen Speicherplatz auch sinvoll in form von Vorhalten von Snaphots nutzen. Also habe ich das Krebsgeschwür wie es hier negativ behaftet genannt wurde, kontrolliert wachsen lassen um es Sinvoll zu nutzen. Damit dies natürlich nicht in die Unendlichkeit weiter anwächst (Irgendwann ist jeder Speicher mal endlich), habe ich für meine Subvolumen folgende Snapshot Rotation eingestellt:
für mein @ Subvolumen worauf mein Root liegt:
- 5 Tägliche Snapshots. Ab dem 6 Tag wird der älteste verworfen
- 1 pacman Installation/Update/Deinstallations Aufruf Snapshot. Dieser nimmt eine Sonderrolle ein, und wir ab dem 2 pacman Aufruf wenn mindestens 10 Minuten dazwischen liegen mit einem aktuelleren ersetzt.
Dies sorgt dafür das ich nach einem Update mein System zurückrollen kann, falls etwas total schiefläuft. Falls mir das erst später auffällt habe ich 5 Tage Zeit dafür. Somit ist das Krebsgeschwür  unter Kontrolle und der Speicherplatz sinnvoll genutzt.
für mein @home Subvolumen:
- 8 Stunden, ab der 9 Stunde wird der älteste verworfen
- 7 Tage, der letzte Stündliche Snapshot des Tages wird zu einem Tages Snapshot.
- 4 Wöchentliche ab dem 8 Tag, wird dieser zum Wochen Snapshot
- 1 Monatlichen
Dies sorgt dafür, dass ich gestaffelt bis 1 Monat in die Vergangenheit noch Daten wiederherstellen kann. Dies hat mir tatsächlich auch schon ein paar GB Daten Download erspart, weil ich ISOs zu früh gelöscht hatte, und sie so wieder aus einem Snapshot ziehen konnte. Und auch hiermit halte ich die Krankheit unter Kontrolle
Zu guter letzt sind hier noch ein paar Statistiken wie sich der Speicherplatz zusammensetzt:
btrfs filesystem du -s /mnt/btrfs-main/@
Total Exclusive Set shared Filename
14.67GiB 23.33MiB 8.99GiB /mnt/btrfs-main/@
|
|
Mein @ Subvolumen Nimmt Gesamt 14.67GiB Daten ein. 23.33MiB Exclusiv das sind Daten die einzigarten sind und nirgendswo anders Referziert sind auch nicht in Snaphots. Dazu zählt aber auch Löschungen deswegen nicht verwirren lassen das Exclusiv + Shared != Total ist. Knappe 9 GiB sind geteilte Daten, diese befinden sich somit auch irgendwo in einem Snapshot.
btrfs filesystem du -s /mnt/btrfs-main/@home/
Total Exclusive Set shared Filename
21.54GiB 5.84GiB 14.94GiB /mnt/btrfs-main/@home/
|
|
Im Home habe ich grade ein wenig aufgeräumt deswegen weis ich das unter Exclusive die knappe 6 GiB von Löschvorgängen kommen.
btrfs filesystem usage /
Overall:
Device size: 931.51GiB
Device allocated: 115.06GiB
Device unallocated: 816.45GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 104.80GiB
Free (estimated): 825.09GiB (min: 416.87GiB)
Free (statfs, df): 825.09GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 259.92MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:111.00GiB, Used:102.36GiB (92.22%)
/dev/mapper/luks-main 111.00GiB
Metadata,DUP: Size:2.00GiB, Used:1.22GiB (61.01%)
/dev/mapper/luks-main 4.00GiB
System,DUP: Size:32.00MiB, Used:16.00KiB (0.05%)
/dev/mapper/luks-main 64.00MiB
Unallocated:
/dev/mapper/luks-main 816.45GiB
|
|
Meine damaligen 80 GiB Speicher, die Allokiert wurden bin ich nun bei knappe 115 GiB, das hauptsächlich davon rührt, das die Snapshots dafür sorgen das Daten, die ich im Live System (so nenne ich es mal) gelöscht habe nicht wieder freigeben wird. Dies wird erst passieren wenn ein Snapshot hinten herausfällt.
Das könnt ihr euch wie auf dem letzten Bild aus meinen vorherigen Post vorstellen. Der Daten Wurm wandert nach hinten immer weiter und schreibt neue Daten. und am Ende bleiben die Daten liegen weil die Snapshots dafür sorgen das der Speicher nicht wieder freigeben wird.
So finde ich das mein Speicherplatz einen besseren Nutzen erfüllt. Ich finde da verhält es sich wie mit dem Arbeitsspeicher, ungenutzter Speicher ist braches Kapital also warum, den nicht sinnvoll nutzen.
Wie lange bzw. wie viele Snapshots jemand vorhalten kann ist natürlich wieder individuell. Somit kann bzw. sollte vielleicht jemand der mehr Daten auf die Festplatte immer wieder schreibt. Kürzere Rotationsintervalle für Snapshots wählen. Dies werde ich z.B. dann erst machen wenn ich den Speicherplatz wirklich für neue Daten benötige.
Momentan haben sich bei mir folgende Menge an Snapshots angesammelt:
❯ yabsnap list
Config: /etc/yabsnap/configs/root.conf (source=/)
Snaps at: /.snapshots/@root-...
20250106173031 S (4 days 3h ago)
20250107193028 S (3 days 1h ago)
20250108193004 S (2 days 1h ago)
20250110113031 S (9h 1m ago)
20250110203132 I (11s ago) pacman -Su
Config: /etc/yabsnap/configs/home.conf (source=/home)
Snaps at: /.snapshots/@home-...
20241230143006 S (1 week 4 days ago)
20250105103028 S (5 days 10h ago)
20250106173031 S (4 days 3h ago)
20250107193028 S (3 days 1h ago)
20250109093035 S (1 day 11h ago)
20250110113031 S (9h 1m ago)
20250110134856 S (6h 42m ago)
20250110173049 S (3h ago)
20250110183024 S (2h 1m ago)
20250110193029 S (1h 1m ago)
20250110203024 S (1m 19s ago)
|
|
LG
Sebastian
|
| « Letzte Änderung: 10. Januar 2025, 19:36:04 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1408
Linux von Innen
|
|
Re:Ein COW Dateisystem erfodert umdenken
« Antwort #4 am: 11. Januar 2025, 07:26:04 »
|
|
Wenn von einem 1TB Dateisystem nur 80GB genutzt sind gebe ich Dir völlig Recht. Wie sieht es aber aus, wenn von dem 1TB Dateisystem 850GB genutzt sind, und bei Arbeiten mit dem Gerät auch mal eben 30...50GB an temporärem Speicher zur Verfügung stehen müssen? Da müsste man dann wohl doch eine größere SSD kaufen ...
Ich habe auch mal überlegt, bei welcher Aktion ich mal den größten Datenverlust hatte... Es war der Hardwareausfall einer Festplatte. Von eben auf jetzt absolut nichts mehr lesbar, und ein RAID hatte ich damals noch nicht. Ein COW-Dateisystem hätte mir da auch nicht geholfen.
Der einzige Fall, bei dem ich so ein Dateisystem verwende ist mein virtuelles Windows. Dort möchte ich nicht das Risiko eingehen, dass nach einem Update gar nichts mehr gehtund verwende ein cow-Dateisystem. Das Windows selbst ist jetzt 72GB groß, der "Datenträger" (es ist eine Datei) ist 180GB groß. Hier stört es mich nicht, dass viel Speicherplatz draufgegangen ist - die Sicherheit dass mein Windows auch nach einem Desaster-Update in Minuten wieder zum Laufen zu bekommen ist ist es mir wert. Bei meinem Linux-System habe ich solche Probleme schon 20 Jahre nicht mehr gehabt: da lege ich größeres Gewicht auf die Geschwindigkeit und den Platzverbrauch. Jeder so, wie es sein Nutzungsprofil am besten meistert.
LG
Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Seiten: [1] 
|
|
|
|
|
|
|
