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.
  • total=491.00GiB, used=490.01GiB

    ....

    Code
    # limits for timeline cleanup
    TIMELINE_MIN_AGE="1800"
    TIMELINE_LIMIT_HOURLY="10"
    TIMELINE_LIMIT_DAILY="10"
    TIMELINE_LIMIT_WEEKLY="0"
    TIMELINE_LIMIT_MONTHLY="10"
    TIMELINE_LIMIT_YEARLY="10"


    Hab ich hier:

    Code
    linux64:~ # grep -i timeline_ /etc/snapper/configs/root 
    TIMELINE_CREATE="no"
    TIMELINE_CLEANUP="yes"
    TIMELINE_MIN_AGE="1800"
    TIMELINE_LIMIT_HOURLY="5"
    TIMELINE_LIMIT_DAILY="7"
    TIMELINE_LIMIT_WEEKLY="0"
    TIMELINE_LIMIT_MONTHLY="0"
    TIMELINE_LIMIT_YEARLY="0"

    Für den Inhalt des Beitrages 135309 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Tip am Rande:
    Denke nicht, das snapper dir Backups ersparen.........

    Auf die Idee würde ich nie kommen.
    Der Rechner startet jede Nacht über's BIOS, macht dann ein rsync auf's NAS, das NAS startet um 5:00 Uhr das Backup-NAS und sichert u.a. das Backup des PCs auf das Backup-NAS, aktuell über 3 Wochen versioniert.
    Snapshot betrachte ich nur als Möglichkeit, Probleme wie z.B. die Installation eines Paketes, dass die Stabilität beeinträchtigt, wieder rückgängig zu machen. Bei Gentoo war das einfacher, weil ich da alle Pakete lokal im Filesystem liegen hatte und notfalls auf ein älteres Paket zurück gehen konnte. Das geht mit dem Repository ja anscheinend nicht.

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

  • Sowie bei dir:

    Code
    NUMBER_MIN_AGE="1800"
    NUMBER_LIMIT="2-10"
    NUMBER_LIMIT_IMPORTANT="4-10"


    Bei mir:


    Code
    linux64:~ # grep -i number_ /etc/snapper/configs/root 
    NUMBER_CLEANUP="yes"
    NUMBER_MIN_AGE="1800"
    NUMBER_LIMIT="2-3"
    NUMBER_LIMIT_IMPORTANT="2-3"

    Für den Inhalt des Beitrages 135311 haftet ausdrücklich der jeweilige Autor: Sauerland

  • @Oceanwaves
    Balance ergibt bei dir Fehler.
    Deswegen mein Lösungsvorschlag in Post #17
    Teste es einfach mal :)


    Hier noch mehr Infos dazu:
    Important: Ranged Compared to Constant Values


    In case quota support is enabled (see Section 7.6.5, “Adding Disk Quota Support”) the limit needs to be specified as a minimum-maximum range, for example 2-10. If quota support is disabled, a constant value, for example 10, needs to be provided, otherwise cleaning-up will fail with an error.


    Quelle:
    Administration Guide | SUSE Linux Enterprise Server 12 SP4

    Für den Inhalt des Beitrages 135313 haftet ausdrücklich der jeweilige Autor: sterun

  • Die Werte hatte SuSE eingetragen. Hab mal beide Limits auf "3" geändert und...

    ....

    Code
    # limits for timeline cleanup
    TIMELINE_MIN_AGE="1800"
    TIMELINE_LIMIT_HOURLY="10"
    TIMELINE_LIMIT_DAILY="10"
    TIMELINE_LIMIT_WEEKLY="0"
    TIMELINE_LIMIT_MONTHLY="10"
    TIMELINE_LIMIT_YEARLY="10"



    Hab ich hier:

    Code
    linux64:~ # grep -i timeline_ /etc/snapper/configs/root 
    TIMELINE_CREATE="no"
    TIMELINE_CLEANUP="yes"
    TIMELINE_MIN_AGE="1800"
    TIMELINE_LIMIT_HOURLY="5"
    TIMELINE_LIMIT_DAILY="7"
    TIMELINE_LIMIT_WEEKLY="0"
    TIMELINE_LIMIT_MONTHLY="0"
    TIMELINE_LIMIT_YEARLY="0"

    ... deine Limits eingetragen.


    Anschließend


    Code
    # btrfs quota rescan -w /
    quota rescan started
    # btrfs balance --full-balance /
    ERROR: error during balancing '/': No space left on device
    There may be more info in syslog - try dmesg | tail


    Hat also auch nix gebracht. Snapshots für / und /home:


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

  • Äh nein, ich hatte ja vorher einen Range "von-bis" eingetragen. Brachte aber bei btrfs balance einen Fehler. Dann auf festen Wert "3" geändert und ebenfalls ein Abbruch bei btrfs balance.


    Vergleich Original zu geändert wegen #17:



    Code
    39,40c39,40
    < NUMBER_LIMIT="2-10"
    < NUMBER_LIMIT_IMPORTANT="4-10"
    ---
    > NUMBER_LIMIT="3"
    > NUMBER_LIMIT_IMPORTANT="3"

    Also mache ich das jetzt wieder rückgängig, weil bei mir ja Quotas aktiv sind.

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

  • Code
    btrfs filesystem df /
    Data, single: total=491.00GiB, used=490.23GiB

    Heißt das jetzt, das root-Filesystem ist praktisch voll?

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

  • Ich hatte exakt den gleichen Fehler.
    Und mit Platzmangel hatte es bei mir definitiv nichts zu tun.
    Bei mir waren von 60 GB noch 52 GB frei.
    Schaue gerade, wie ich das gelöst habe.
    Teste noch einmal als Root (su):
    btrfs quota disable /
    Läuft "balance" dann?
    Danach wieder einschalten mit:
    btrfs quota enable /
    Ich meine dies, in Verbindung mit der Änderung der zwei NUMBER_LIMIT Werte war die Lösung.
    Seit dem hatte ich nie wieder Probleme mit BTRFS und auch diverse Cloning-Programme laufen perfekt (Clonezilla z.B.).

    Für den Inhalt des Beitrages 135317 haftet ausdrücklich der jeweilige Autor: sterun

  • Ich probier's mal. Meine aber gelesen zu haben, wenn man Snapshiots mit btrfs nutzt, dass dann Quotas auf jeden Fall aktiviert sein sollten. Und die NUMBER_LIMIT-Werte in dem Fall "von-bis" sein sollten (wie ich es ja ursprünglich hatte und jetzt auch wieder habe).

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

  • Nein, geht auch nicht:


    Code
    # btrfs quota disable /
    # btrfs balance --full-balance /
    ERROR: error during balancing '/': No space left on device
    There may be more info in syslog - try dmesg | tail

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