Empfehlungen für btrfs-Rootpartitionen?

Hinweis: In dem Thema Empfehlungen für btrfs-Rootpartitionen? gibt es 5 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.

    Hallo!


    Gehen wir von einem Benutzer aus, der (so wie ich) beim Installieren von openSUSE 13.2 auf die Voreinstellungen vertraut hat. Das heißt, die Root-Partition benutzt btrfs. Dank Snapper und dank der btrfs-Metadaten kann sich die Root-Partition in der Default-Größe (20GB bei mir) schnell als zu klein erweisen, was der Benutzer mit "df" nicht erkennen kann und wodurch der Computer unbenutzbar werden kann.


    Natürlich könnte man dieses Problem durch eine Neuinstallation mit ext4 für die Root-Partition oder auch mit einer Vergrößerung der Root-Partition lösen. Aber ich schlage vor, in diesem Thread Möglichkeiten zu behandeln, wie man *ohne* eine Neuinstallation mit der Situation klar kommt.


    Man sollte sicherlich die Speicherung von Snapshots beschränken und man sollte für die zügige Löschung temporärer Dateien sorgen (Sehe ich das richtig, dass Yasts "/etc/sysconfig-Editor" dies nicht mehr anbietet?). Für die folgenden weiteren Ideen fehlt mir die Erfahrung, vielleicht kann da jemand weiterhelfen?


    1. Ist es sinnvoll, einen Cron-Job zu erzeugen, der regelmäßig das btrfs balanciert und/oder defragmentiert? Wenn ja, wie würde man so etwas machen?


    2. Ist es sinnvoll, die Root-Partition zu komprimieren? Hat jemand Erfahrung, was die Folgen sind? Wird der Computer dadurch spürbar langsamer?
    Falls es sinnvoll ist: lzo oder zlib? Und geht das mit folgenden zwei Schritten, oder ist noch mehr/anderes nötig?


    2a) /etc/fstab edieren und dort

    Code
    UUID=... / btrfs defaults 0 0

    ersetzen durch

    Code
    UUID=... / btrfs defaults,compress=lzo 0 0

    (Folge: Neue Dateien werden komprimiert) Müsste man das zusätzlich auch für subvolumes machen?


    2b) Alte Dateien komprimieren mit

    Code
    btrfs filesystem defrag -r -clzo /


    Was könnte man noch tun, um mit dem knappen Platz dauerhaft auszukommen?


    Viele Grüße,
    Simon

    Für den Inhalt des Beitrages 78680 haftet ausdrücklich der jeweilige Autor: S. King

    Zitat von S. King

    1. Ist es sinnvoll, einen Cron-Job zu erzeugen, der regelmäßig das btrfs balanciert und/oder defragmentiert?


    Bestimmt keine schlechte Idee!

    Zitat von S. King

    Wenn ja, wie würde man so etwas machen?


    Sorry, da muss ich passen :S


    Zitat von S. King

    Was könnte man noch tun, um mit dem knappen Platz dauerhaft auszukommen?


    Also ich würde es ganz einfach lösen: Snapper-Automatisierung komplett ausschalten und nur noch nach Bedarf manuell Snapshots erstellen und löschen. Zusätzlich entweder mit Cron-Job oder manuell regelmäßig Balancieren und Defragmentieren. Sollte meiner Ansicht nach ausreichen.

    Hi Simon,
    deine Situation ist ja nun bissel verkorkst, wie wir wissen. Du hast ja gerade erst die Erfahrung gemacht mit den Meta-Daten des btrfs-Dateisystems. Mal paar Gedanken dazu von mir. Zuerst einmal die Frage in die Runde, wer das Snapper-Tool schon mal zur Datenwiederherstellung genutzt hat und bei wem das auch funktioniert hat.
    Du selbst (glaube ich mich zu erinnern) hast das erfolglos versucht. Stelle ich mal eine weitere Frage: Warum sich mit der Konfiguration und Pflege eines Tools herumärgern, dass nichts anderes macht als meine Platte vollzuschreiben?
    Deshalb habe ich Snapper deinstalliert.
    Snapper ist aber bei der ganzen btrfs/snapper Geschichte das wohl kleinere Problem. Das größere Problem sind die meta-daten von btrfs.
    Einen cron-Job erzeugen ist möglich, ich weiß aber jetzt nicht, ob das als User oder als Root ausgeführt werden muß. Ich denke aber mal als root, was die Sache nicht einfacher macht.
    In dem Falle mußt du den cronjob in die root-crontab eintragen. Sonst kommt es zu einer Fehlermeldung.
    Ehe ich dir den Aufbau eines cronjobs erklärt habe mit den Zeiten etc. schau dir es selber einmal an:


    klick


    Von einer Komprimierung mit lzo rate ich dringend ab. Grub2 kann die komprimierte grub.cfg nicht auslesen, was zu einem nicht mehr startenden System führt. Zumindest war das bei älteren Kerneln mal der Fall. Ich würde das Risiko nicht eingehen und überhaupt auf eine Komprimierung verzichten. In einem Zeitalter wo Festplatten im Terra-Bereich nur "Pfennige" kosten macht eine Komprimierung eigentlich nur in den wenigsten Fällen Sinn. Wenn komprimieren dann mit zlib.


    Und so ganz langsam nähern wir uns dem Windows-Betriebssystem mit täglicher Defragmentierung und ähnlichen Spielen.


    Zusammenfassende Gedanken: Snapper entweder deinstallieren oder mit Yast oder auf anderem Wege so einstellen, das er nur einen Schnappschuss auf Anweisung erstellt (wie das glaube bei Windows auch der Fall ist). Also die Automatik komplett aus.
    Cronjobs für Meta-Daten im btrfs-Dateisystem sind nicht schlecht wenn man es denn verwendet. Allerdings kann so eine Defragmentierung eine Weile dauern und es wäre möglich, dass diese das System stark verlangsamt.
    Also entweder den cronjob beim Herunterfahren ausführen oder manuell, wenn es eben mal passt.


    best regards ;)

    Hallo Alero!

    Zitat von Alero

    Zuerst einmal die Frage in die Runde, wer das Snapper-Tool schon mal zur Datenwiederherstellung genutzt hat und bei wem das auch funktioniert hat.
    Du selbst (glaube ich mich zu erinnern) hast das erfolglos versucht.

    Das würde ich so nicht formulieren. Als meine Root-Partition voll war, also bevor ich die meisten Snapshots löschte und das Dateisystem balancierte und defragmentierte, habe ich versucht, von einem Snapshot zu booten. Das hat in der Tat nicht funktioniert, aber das dürfte wohl eher daran liegen, dass die Root-Partition ja zu diesem Zeitpunkt noch voll war.


    Wie dem auch sei, die automatische Aktivität von Snapper zu reduzieren oder ganz auszuschalten, ist vermutlich empfehlenswert.


    Viele Grüße,
    Simon

    Für den Inhalt des Beitrages 78691 haftet ausdrücklich der jeweilige Autor: S. King

    Im Zuge einer anderen Angelegenheit, mit der ich mich gerade befasse, ist es unter bestimmten Voraussetzungen auch möglich die swap-Partition zu verkleinern und den frei werdenden Speicher dem System, also z.B. root, zur Verfügung zu stellen.

    Besser ein Ende mit Schrecken als ein Schrecken ohne Ende. Ich würde die Notbremse benutzen und die Kiste mit ext4 neu aufsetzen. Das Wetter ist gerade danach. Wenn das Wetter besser wird, ist es schade um die Zeit.


    Falk

    Für den Inhalt des Beitrages 78704 haftet ausdrücklich der jeweilige Autor: Falk2