Tumbleweed Btrfs: System friert kurz nach Start reproduzierbar zeitweise ein
- Oceanwaves
- Erledigt
-
-
Danke, ich versuche jetzt erst mal die Geschichte mit dem zusätzlichen USB-Stick.
Obwohl ein btrfs filesystem show ja eigentlich sagt, dass noch massig Platz vorhanden ist:
-
Der USB-Stick war noch nicht die Lösung:
CodeStarting balance without any filters. ERROR: error during balancing 'fulldisk': No space left on device There may be more info in syslog - try dmesg | tail
Also mal den anderen Vorschlag probiert, aber ich muss mit dusage auf mind. 80% hoch, damit etwas passiert:
Code# btrfs fi balance start -dusage=70 / Done, had to relocate 0 out of 517 chunks # btrfs fi balance start -dusage=80 / Done, had to relocate 1 out of 517 chunks
Wie voll ist denn meine 1 TB-SSD jetzt eigentlich?btrfs filesystem show sagt:
Codebtrfs filesystem show Label: none uuid: c38f15f5-eed1-4260-b0ca-0800c4f7e814 Total devices 1 FS bytes used 511.53GiB devid 1 size 929.02GiB used 516.03GiB path /dev/nvme0n1p1
Also knapp die Hälfte noch frei.
btrfs filesystem df / hingegen sagt:
Codebtrfs filesystem df / Data, single: total=510.00GiB, used=509.33GiB System, single: total=32.00MiB, used=96.00KiB Metadata, single: total=6.00GiB, used=2.21GiB GlobalReserve, single: total=512.00MiB, used=0.00B
Also nur noch 0,67 GB frei? Das kann doch auch nicht sein.
Ich lösche jetzt mal die Snapshots für /home und anschließend die Konfiguration für /home.
-
Und auch die Konfiguration für /home kann ich nicht löschen. snapper löscht zwar die Snapshots bis auf #0, bricht dann aber ab:
Codesnapper -c home delete-config Deleting config failed (deleting snapshot failed). snapper -c home ls # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ---+--------+-------+------+------+------------+---------+-------------+--------- 0 | single | | | root | | | current |
-
Ich hoffe, ich habe das Problem jetzt behoben, mit etwas Recherche und Experimentieren ist es mir endlich gelungen, die Snapper-Konfiguration für /home komplett und sauber zu löschen. Nachdem sich in den letzten 4 Tagen wieder ganze 12 Snapshots (!!) für /home angesammelt hatten und das System wieder sehr langsam wurde, habe ich den "Stecker für /home gezogen", auch wenn es nicht ganz leicht war. Ausgangssituation:
Code
Alles anzeigenfrodo:~ # snapper list-configs Config | Subvolume -------+---------- home | /home root | / frodo:~ # snapper -c home ls # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ----+--------+-------+--------------------------+------+------------+----------+-------------+--------- 0 | single | | | root | | | current | 1 | single | | Tue Aug 27 04:00:26 2019 | root | 1.12 GiB | timeline | timeline | 4 | single | | Wed Aug 28 04:00:09 2019 | root | 272.13 MiB | timeline | timeline | 5 | single | | Wed Aug 28 07:00:01 2019 | root | 47.01 MiB | timeline | timeline | 6 | single | | Wed Aug 28 08:00:27 2019 | root | 44.07 MiB | timeline | timeline | 7 | single | | Wed Aug 28 20:00:09 2019 | root | 8.11 MiB | timeline | timeline | 8 | single | | Wed Aug 28 21:00:09 2019 | root | 8.27 MiB | timeline | timeline | 9 | single | | Thu Aug 29 04:00:10 2019 | root | 28.80 MiB | timeline | timeline | 10 | single | | Thu Aug 29 07:00:03 2019 | root | 35.15 MiB | timeline | timeline | 11 | single | | Thu Aug 29 08:00:03 2019 | root | 44.62 MiB | timeline | timeline | 12 | single | | Fri Aug 30 04:00:15 2019 | root | 55.14 MiB | timeline | timeline | 14 | single | | Fri Aug 30 07:00:49 2019 | root | 24.44 MiB | timeline | timeline | 15 | single | | Fri Aug 30 08:00:49 2019 | root | 10.82 MiB | timeline | timeline | frodo:~ # frodo:~ # snapper -c home delete-config Deleting config failed (deleting snapshot failed). frodo:~ # snapper -c home ls # | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata ---+--------+-------+------+------+------------+---------+-------------+--------- 0 | single | | | root | | | current |
Wie man sehen kann, hat ein snapper -c home delete-config zwar alle Snapshots bis auf den aktuellen gelöscht. Aber nicht die Konfiguration für /home! Stattdessen fing btrfs an, das Filesystem zu säubern. btrfs-cleaner und btrfs-transaction haben dabei so viel Ressourcen verbraucht, dass das System für über eine halbe Stunde praktisch nicht mehr zu benutzen war. Den Spotify-Client sowie eine laufende VirtualBox-Session hat es komplett zerrissen, die Prozesse waren irgendwann plötzlich weg. Das gesamte System war immer nur mal kurzzeitig (20-30 Sekunden) nutzbar, danach reagierte es 2, 3 Minuten lang nicht mehr.Wie habe ich nun die Konfiguration für /home wegbekommen? Ich habe /etc/sysconfig/snapper editiert und home aus dem Parameter SNAPPER_CONFIGS entfernt. Anschließend habe ich mit btrfs subvolume delete /home/.snapshots das Snapshot-Verzeichnis gelöscht. Hier fand sich dann auch die vermutliche Ursache, warum ich die Konfiguration nicht einfach mit snapper -c home delete-config löschen konnte. Es existierte nämlich unterhalb von /home/.snapshots noch ein Snapshot mit der Nummer 13 (richtig, der taucht oben in der Liste der Snapshots gar nicht auf). Warum genau der dort liegen geblieben ist, lässt sich nicht mehr feststellen. Ich habe ihn nämlich ebenfalls mit btrfs subvolume delete /home/.snapshots/13/snapshot/ gelöscht.
Ich hoffe, dass ich damit jetzt Ruhe habe. Die ersten Wochen lief das System mit den Snapshots für / nämlich ohne Probleme.
Fazit für mich: Snapper/btrfs hat noch Verbesserungspotential. Die Hardware wurde im Juni angeschafft und sollte performant genug sein, um Snapshots zu verwalten. Es handelt sich um ein Asus ROG STRIX X470-F GAMING Board mit einem AMD Ryzen 7 2700X-Prozessor, 32 GB RAM, die gesamte Installation erfolgte auf einer Samsung NVMe.2-SSD 970 EVO Plus mit 1 TB. Eine Festplatte besitzt der Rechner nicht.
-
Es ergibt keinen Sinn, /home in snapper einzubinden. Bei einem Zurücksetzen wegen kaputten system löscht du dir Dokumente, bzw. alle Änderungen in /home. Deswegen ist btrfs auch kein Backup.
Als Leihe vermute ich, dass du Btrfs ans Limit gebracht hast, da die snapshot diffs bei dir z.T. über 700mb groß sind bzw. Zwischen dem ersten und letzten mehrere Dutzend Gb. Das ist ungefähr der Umfang, wenn du von Leap auf TW upgradest. Ansonsten sind die diffs normalerweise nur wenige 100 KB oder mb groß.
Mit solchen snapshot Größen musst du quasi ständig den current snapshot neu definieren, weil sonst die diff zwischen snapshot 1 und xxx zu riesig wird. Btrfs Snapshots sind vom Konzept her nicht für große sich verändernde Datenmengen gedacht, also nicht für /home.
-
Es ergibt keinen Sinn, /home in snapper einzubinden. Bei einem Zurücksetzen wegen kaputten system löscht du dir Dokumente, bzw. alle Änderungen in /home. Deswegen ist btrfs auch kein Backup.
Als Leihe vermute ich, dass du Btrfs ans Limit gebracht hast, da die snapshot diffs bei dir z.T. über 700mb groß sind bzw. Zwischen dem ersten und letzten mehrere Dutzend Gb. Das ist ungefähr der Umfang, wenn du von Leap auf TW upgradest. Ansonsten sind die diffs normalerweise nur wenige 100 KB oder mb groß.
Mit solchen snapshot Größen musst du quasi ständig den current snapshot neu definieren, weil sonst die diff zwischen snapshot 1 und xxx zu riesig wird. Btrfs Snapshots sind vom Konzept her nicht für große sich verändernde Datenmengen gedacht, also nicht für /home.
Das sehe ich nicht. Das Diff zu #1 sind 1,12 GB, #2 272 MB, danach zwischen 8 und 55 MB. Wo siehst du da "mehrere Dutzend GB"?