Sebastian
YaBB God
 Offline
Einträge: 628
|
 |
Vor und Nachteile eines Btrfs
« am: 30. Dezember 2024, 17:45:02 »
|
|
Einleitung:
Hallo Suletuxe,
Ich möchte hier kurz auflisten, welche Erfahrungen ich mit Btrfs bis jetzt gemacht habe.
Die Auflistung bezieht sich dabei auf meine Arbeitsweise. Hauptsächlich reines Internet Surfen, und ausprobieren von neuen Dingen. Dazu gehört auch das Arbeiten mit vielen VMs, um Dinge auszuprobieren, bevor ich diese in mein System intrigiere. Also keine schreibintensiven Dinge, wo massenhaft Daten erzeugt oder kopiert werden müssen. Also eher der Heimanwender. Für Images der VMs habe ich die COW Funktion ausgeschaltet.
Das Btrfs, das nun auf mein Notebook läuft, erstreckt sich als eine große Partition, die in einem Luks Container/Volumen angelegt wurde. Auf einer 1 TB großen SSD. Die SSD erwähne ich extra, da auf einer HDD ein Btrfs durch sein COW ganz anders performt und ich damit keine Erfahrung habe.
Hinweis:
Die Vor- bzw. Nachteile sind nicht alle zu verallgemeinern. Einige sind für den ein mehr von Vor- bzw. Nachteil als bei jemanden anderen. Es kommt stark darauf an wie viel Nutzen ihr aus den gebenen Funktionen zieht und wie ihr mit eure Computer arbeitet.
Vorteile:
Dann fange ich am besten mal mit den Vorteilen an, die mir Btrfs in meinen Alltag gebracht hat.
- Verzicht auf LVM: durch Btrfs kann ich nun auf LVM verzichten, da ich eine logische Datentrennung nun mithilfe Btrfs eigenen Subvolumen durchführen kann.
- Geteilter Speicherplatz: Alle Subvolumen teilen sich den kompletten Speicherplatz. Somit ist keine nachträgliche Größenänderung von logischen Volumen mehr nötig. (Durch Quatas könnte man aber auch den Speicherplatz beschränken)
- Verwendung von Snapshots: Durch Btrfs eigene Subvolumen Snapshot Funktion, ist auch hier ein anlgen eines Snapshots in einer Sekunde erstellt. Ohne extra ungenutzten Speicher vorhalten zu müssen (wie es bei einer LVM Gruppe der Fall war). Dieser kann nun dynamisch allokiert werden.
- Rollback möglich: Durch das Automatisieren der Erstellung von Snapshots durch yabsnap, bin ich nun in der lange mein System auf ein Zeitpunkt zurückzurollen, wo es noch funktioniert hat. (Noch nie gebraucht, aber Psychologisch gut zu wissen das man das könnte)
- Detektieren von Defekten Daten: Durch die Checksummen Bildung ist Btrfs in der lange einem mitzuteilen das Daten nicht mehr in dem Zustand vorliegen wie sie abgespeichert wurden. Bei Dopplung der Daten (entsprechend Profil oder Raid) ist auch eine Selbstheilung der Daten möglich, indem die intakte Kopie noch mal kopiert wird (Das macht Btrfs dann selbst).
- Kopiervorgänge sind wesentlich schneller: Finden Kopiervorgänge im selben Dateisystem statt (ich spreche nicht von Verschieben) sind diese mithilfe eines Reflinks in einer Sekunde erledigt. Mein Dateimanager Thunar zieht Out of the box von dieser Funktion seinen nutzen, und erstellt automatisch Kopien per reflink falls ich eine Datei in ein anderes Verzeichnis kopiere. Dies merkt man besonders, wenn ISOs oder Image Dateien kopiert werden. So ist eine Kopie in einem Wimpernschlag erstellt.
- Referenzierte Kopien belegen keinen zusätzlichen Speicherplatz: Erst ab dem Zeitpunkt an dem eine Änderung an der Kopie vorgenommen wird, wird Speicherplatz für diese Änderung verbraucht.
- Komprimierung: Durch die Automatische Komprimierung wird noch einmal mehr Speicherplatz eingespart.
Besonders das Erstellen einer sofortigen Kopie möchte ich nicht mehr missen, da ich häufiger mal große Dateien zu Testzwecken modifizieren möchte, und so nicht mehr warten muss bis eine Kopie wirklich angelegt wurde. Und es werden so auch keine unnötigen Schreibvorgänge auf der SSD verursacht.
Zudem führt Btrfs Buch darüber falls Daten nicht gelesen werden können oder wiederhergestellt werden mussten den Counter kann man jederzeit Abfragen:
sudo btrfs device stats /
[/dev/mapper/luks-main].write_io_errs 0
[/dev/mapper/luks-main].read_io_errs 0
[/dev/mapper/luks-main].flush_io_errs 0
[/dev/mapper/luks-main].corruption_errs 0
[/dev/mapper/luks-main].generation_errs 0
|
|
Also meinem Dateisystem geht es bis jetzt noch richtig gut  und es musste da noch nichts repariert werden. Falls sich diese werte erhöhen, so kann auch ein Hardware defekt vorliegen.
Nachteile:
Nachteile gibt es für die Art und Weise wie ich mein System nutze eigentlich nicht. Trotzdem möchte ich den einen Nachteil, den man gegenüber von Ext4 hat nicht unerwähnt lassen.
- Btrfs ist gegenüber zu Ext4 langsamer: In der Theorie ist Btrfs aufgrund der Arbeitsweise wie Btrfs arbeitet (COW) langsamer.
- Speicherplatz muss freigeben werden: Da Btrfs nach einer gewissen Zeit Daten wild über den Datenträger verteilt. Muss eventuell auch bei nutzung von nur einem Gerät ein btrfs balance gemacht werden. Damit btrfs die Daten auf dem Datenträger neu allokiert und Datenblöcke wieder freigeben werden können. Dies kommt auch stark auf die Arbeitsweise an wie häufig und ob man das überhaupt machen muss drauf an. Dies wird man häufiger machen müssen wenn das Dateisystem rand voll gepackt wird. Ich selbst der nur 80 GB von seinem 1 TB nutzt musste das noch nie ausführen.
Ich schreibe hier extra Theorie da dies stark drauf ankommt, welche Arbeiten man auf dem Dateisystem durchführt. Ich wie gesagt, merke da kein Unterschied zu Ext4. Da ich den Geschwindigkeitsvorteil von Ext4 vorher nie ausgenutzt habe.
Hier ist ein Beispiel wie viel Speicherplatz mein Btrfs verwendet:
sudo btrfs filesystem usage /
Overall:
Device size: 931.51GiB
Device allocated: 85.02GiB
Device unallocated: 846.49GiB
Device missing: 0.00B
Device slack: 0.00B
Used: 83.30GiB
Free (estimated): 848.11GiB (min: 424.86GiB)
Free (statfs, df): 848.11GiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 196.47MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:83.00GiB, Used:81.38GiB (98.05%)
/dev/mapper/luks-main 83.00GiB
Metadata,DUP: Size:1.00GiB, Used:982.67MiB (95.96%)
/dev/mapper/luks-main 2.00GiB
System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
/dev/mapper/luks-main 16.00MiB
Unallocated:
/dev/mapper/luks-main 846.49GiB
|
|
Ich habe 83 GiB an Daten diese nehmen ca. 81.38GiB tatsächlichen Speicherplatz durch die Komprimierung (zstd level 3) ein. Für diese Daten+Metadaten wurde auf meiner SSD 85.02GiB Speicher allokiert. Somit hat Btrfs zum arbeiten noch 846.49GiB zum Arbeiten übrig. ein Balance würde jetzt den Wert des Allokierten Speichers an die tatsächliche Datenmenge bringen.
LG
Sebastian
|
Autor
Gespeichert
