Defragmentation unter Btrfs?

Seit kurzem habe ich Manjaro (KDE) mal mit Btrfs installiert (vorgegebene Partitionierung von Calamares). Nun habe ich gehört, dass es bei Btrfs wieder ein Problem mit Fragmentierung geben kann. Da ich meine Systempartition auf einer SSD habe, frage ich mich jetzt, sollte ich da von Zeit zu Zeit mal defragmentieren (mit Btrfs-maintenance im Btrfs-Assistant) oder ist das wegen der zusätzlichen Schreibvorgänge auf der SSD lieber sein zu lassen?

https://wiki.archlinux.org/title/Btrfs#Defragmentation

1 Like

Gut, aber das, was da zu lesen ist, war mir schon bekannt. Mir geht es eher darum, ob eine regelmäßige Defragmentierung auf einer SSd sinnvoll ist, oder eher auf dauer Schaden anrichtet. Sonst könnte ich ganz einfach eine regelmäßige Defrag im Btrfs-Asistant anordnen.

Nein, auf einer SSD ist Defragmentierung, wie auch Balance nicht empfohlen, weil es zusätzliche Schreibzyklen verbrennt und keinen Performance-Vorteil bietet.

Defragmentierung ist nur HDDs empfohlen, auch sollte es um Fragmentierung zu minimieren mit der Option “autodefrag” eingehängt werden. Allerdings ist Fragmentierung ganz natürlich auf einem COW Dateisystem, da es nie Dateien überschreibt, sondern immer neue Dateien erstellt, bei jedem Schreiben, was es auch perfekt zum wiederherstellen von gelöschten Dateien macht.

Ich konnte mehrmals versehentlich gelöschte Dateien wiederherstellen mit: GitHub - danthem/undelete-btrfs: A script that attempts to undelete files in a BTRFS file system. Make sure you read the README. Dazu musst du aber in einen Live-Sitzung booten, wenn es deinen Wurzelverzeichnis ist, da die Partition ausgehängt sein muss.

Mit einer Defragmentierung würdest du auch die Wahrscheinlichkeit deine Dateien wiederherstellen zu können, drastisch minimieren.

Wenn du dennoch glaubst, defragmentieren zu müssen, dann beachte einfache nur Dateien mit einer hohen Datei-Fragmentierung ab 500. Bei Datei-Fragmentierung ca. ab 10000, wäre die nodatacow Markierung fällig, (anfällig sind zb Datenbanken wie sqlite, oder VM Images) also:

sudo chattr +C /pfad/zu/datei

Damit findest du Dateien, die eine Datei-Fragmentierung über 500 haben:

sudo find / -xdev -type f | \
xargs filefrag 2>/dev/null | \
sed 's/^\(.*\): \([0-9]\+\) extent.*/\2 \1/' | \
awk -F ' ' '$1 > 500' | \
sort -n -r 

Siehe auch:

Balance ist auch eine Art Defragmentierung, jedoch nicht der Extents, sonder der Chunks. Es befüllt die 1GB Chunks wieder. Stelle es dir mal so vor: Du hast Eimer in Reihe mit exakt einem Liter. Du nimmst Wasser aus einem in Mitte (löscht Dateien). Was eine Balancierung machen würde, ist Wasser aus dem letzten Eimer nehmen und die ersten Eimer kippen, bis diese voll sind. Ggf. Kannst du den letzten Eimer entfernen, da leer.

Da BTRFS empfindlich auf zu wenig freien Speicher regiert, wäre ein kontrollierter Balance in manchen Fällen notwendig, um Speicher freizugeben. Zum Beispiel (befülle alle Daten-Chunks bis auf 90%):

sudo btrfs balance start -dusage=90 --bg /
sudo watch -n5 btrfs balance status /

:warning: Niemals eine volle Balancierung vornehmen, außer du konvertierst in ein anderes Profil, zb Single → DUP oder Single → RAID1 usw.

Jedenfalls ist das in der Regel nicht notwendig. Je nach Nutzungsgrad und freier Speicher, muss man das selbst abwägen. Ich mach das on demand mal alle ca. 6 Monate. Oder wenn der Speicher voll ist, lösche ich de Cache und andere unnötige Daten und führe eine kontrollierte Balancierung durch.

Generell gilt auch hier: Immer 20% Speicher freihalten auf der Partition, wo sich das Wurzelverzeichnis befindet.

2 Likes

(befülle bewege alle Daten-Chunks bis auf 90% die weniger als 90% voll sind):

In Wirklichkeit entscheidet der Filter (-dusage=XX) ob ein Chunk am Balance teilnimmt.

  • Er nimmt nicht Teil, wenn er selbst voller ist, als das angegebene Maß XX%
  • Er nimmt nicht Teil, wenn er ganz leer ist
  • Er nimmt Teil, wenn er mehr als XX% Platz freigeben kann
  • Er nimmt nicht Teil, wenn er der aktuelle offene Chunk ist

Beispiel: 4 Chunks voll, 1 Chunk 20%(offen), 1 Chunk leer
→ bleibt so :wink: bei Filtern zwischen 0 und 99%

[xxxxxxxxxx][xxxxxxxxxx][xxxxxxxxxx][xxxxxxxxxx][xx>________][__________]

Beispiel: 1 Chunk voll, 3 mit Platz, 1 Chunk 20%(offen), 1 Chunk leer

[aaa_____aa][bb__b_b_bb][______cccc][xxxxxxxxxx][xx>________][__________]

Was btrfs macht (grob vereinfacht :wink: ):

filter =49%

[aaa_____aa][bb__b_b_bb][______cccc][xxxxxxxxxx][xx>________][__________]
  • Chunk a hat mehr als 49% frei und wird eingesammelt
[aaa_____aa][bb__b_b_bb][______cccc][xxxxxxxxxx][xxaaaaa>___][__________]
  • nachdem die Daten geschrieben sind, kann der bisherige Chunk a freigegeben werden.
[__________][bb__b_b_bb][______cccc][xxxxxxxxxx][xxaaaaa>___][__________]
  • Chunk b hat weniger als 49% frei, und nimmt nicht Tei.
[__________][bb__b_b_bb][______cccc][xxxxxxxxxx][xxaaaaa>___][__________]
  • Chunk c hat mehr als 49% frei, und wird eingesammelt
[__________][bb__b_b_bb][______cccc][xxxxxxxxxx][xxaaaaaccc>][__________]
  • Damit wird dann der offene Chunk voll, und es muß ein neuer angefangen werden. In den kommen die restlichen Daten von c
[c>_________][bb__b_b_bb][______cccc][xxxxxxxxxx][xxaaaaaccc][__________]
  • nachdem die Daten von c komplett geschrieben sind, kann der bisherige Chunk c freigegeben werden.
[c>_________][bb__b_b_bb][__________][xxxxxxxxxx][xxaaaaaccc][__________]

filter =80%

[c>_________][bb__b_b_bb][__________][xxxxxxxxxx][xxaaaaaccc][__________]
  • Chunk c ist der aktuelle chunk und nimmt nicht Teil
[c>_________][bb__b_b_bb][__________][xxxxxxxxxx][xxaaaaaccc][__________]
  • Chunk b liegt unter den 80% und wird eingesammelt
[cbbbbbb>___][bb__b_b_bb][__________][xxxxxxxxxx][xxaaaaaccc][__________]
  • Dann kann b freigegeben werden
[cbbbbbb>___][__________][__________][xxxxxxxxxx][xxaaaaaccc][__________]

Ich hoffe, ich hab mich nirgends vertippt :wink:

Du kannst btrfs live beim balance beobachten mit

extra/btrfs-heatmap

:footprints:

You can find good Information about Btrfs in the wiki ( → fragmentation)

Google ist dein Freund und übersetzt dir das.

3 Likes

Danke für Eure ausführlichen Antworten, @megavolt , @andreas85 .

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.