Tumbleweed Btrfs: System friert kurz nach Start reproduzierbar zeitweise ein

Hinweis: In dem Thema Tumbleweed Btrfs: System friert kurz nach Start reproduzierbar zeitweise ein gibt es 36 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • 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:

    Code
    btrfs filesystem show
    Label: none  uuid: c38f15f5-eed1-4260-b0ca-0800c4f7e814
            Total devices 1 FS bytes used 510.71GiB
            devid    1 size 929.02GiB used 520.03GiB path /dev/nvme0n1p1

    Für den Inhalt des Beitrages 135349 haftet ausdrücklich der jeweilige Autor: Oceanwaves

  • Der USB-Stick war noch nicht die Lösung:

    Code
    Starting 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:

    Code
    btrfs 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:

    Code
    btrfs 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.

    Für den Inhalt des Beitrages 135361 haftet ausdrücklich der jeweilige Autor: Oceanwaves

  • 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:

    Code
    snapper -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     |

    Für den Inhalt des Beitrages 135366 haftet ausdrücklich der jeweilige Autor: Oceanwaves

  • 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:


    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.

    Für den Inhalt des Beitrages 135470 haftet ausdrücklich der jeweilige Autor: Oceanwaves

  • 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.

    PRAISE THE OMNISSIAH

    Für den Inhalt des Beitrages 135473 haftet ausdrücklich der jeweilige Autor: Scytale

  • 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"?

    Für den Inhalt des Beitrages 135476 haftet ausdrücklich der jeweilige Autor: Oceanwaves