Niedriger Festplattenspeicher unter "Dateisystemstamm" -Fehler in openSUSE Leap 15

692
Human

Problem

Anscheinend habe ich zu wenig Speicherplatz auf meiner Root-Partition. Bei der Installation meines Betriebssystems (openSUSE Leap 15 auf einer VM) habe ich die Standardpartitionierung ausgewählt. Jetzt bekomme ich die Warnung / Fehler zu wenig Speicherplatz unter "Filesystem root" . Es warnt mich, wenn ich das System starte, und wenn ich versuche, ein großes Projekt zu kompilieren, wird ein Fehler ausgegeben.

Analyse

Lassen Sie uns die Speichersituation überprüfen:

Plattenspeicherplatznutzung des Berichtsdateisystems:

$ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 13G 0 13G 0% /dev tmpfs 13G 34M 13G 1% /dev/shm tmpfs 13G 82M 13G 1% /run tmpfs 13G 0 13G 0% /sys/fs/cgroup /dev/sda2 40G 38G 2.2G 95% / /dev/sda2 40G 38G 2.2G 95% /root /dev/sda2 40G 38G 2.2G 95% /boot/grub2/i386-pc /dev/sda3 204G 165G 40G 81% /home /dev/sda2 40G 38G 2.2G 95% /boot/grub2/x86_64-efi /dev/sda1 500M 5.0M 495M 1% /boot/efi /dev/sda2 40G 38G 2.2G 95% /usr/local /dev/sda2 40G 38G 2.2G 95% /srv /dev/sda2 40G 38G 2.2G 95% /opt /dev/sda2 40G 38G 2.2G 95% /.snapshots /dev/sda2 40G 38G 2.2G 95% /tmp /dev/sda2 40G 38G 2.2G 95% /var tmpfs 2.6G 20K 2.6G 1% /run/user/462 tmpfs 2.6G 48K 2.6G 1% /run/user/1000

Schätzung des Dateibereichs:

$ sudo du -hsx /* | sort -rh | head -n 40 [sudo] password for root:  du: cannot access '/proc/8809/task/8809/fd/4': No such file or directory du: cannot access '/proc/8809/task/8809/fdinfo/4': No such file or directory du: cannot access '/proc/8809/fd/4': No such file or directory du: cannot access '/proc/8809/fdinfo/4': No such file or directory 51G /home 5.5G /usr 972M /opt 894M /var 792M /lib 63M /boot 38M /tmp 24M /etc 18M /run 11M /sbin 11M /lib64 2.1M /bin 320K /root 0 /sys 0 /srv 0 /selinux 0 /proc 0 /mnt 0 /dev  $ sudo du -hsx /.snapshots 2.2M /.snapshots  $ sudo du -hs /.snapshots 129G /.snapshots

Schnappschüsse auflisten, wie von @Kamil Maciorowsk vorgeschlagen:

$ sudo snapper list Type | # | Pre # | Date | User | Cleanup | Description | Userdata  -------+-----+-------+----------------------------------+------+---------+-----------------------+-------------- single | 0 | | | root | | current |  single | 1 | | Tue 02 Oct 2018 02:42:20 PM CEST | root | | first root filesystem |  pre | 74 | | Mon 08 Oct 2018 03:25:32 PM CEST | root | number | zypp(zypper) | important=yes post | 75 | 74 | Mon 08 Oct 2018 03:27:17 PM CEST | root | number | | important=yes pre | 82 | | Tue 16 Oct 2018 09:11:33 AM CEST | root | number | zypp(zypper) | important=yes post | 83 | 82 | Tue 16 Oct 2018 09:12:04 AM CEST | root | number | | important=yes pre | 108 | | Thu 01 Nov 2018 01:25:41 PM CET | root | number | zypp(zypper) | important=yes post | 109 | 108 | Thu 01 Nov 2018 01:27:12 PM CET | root | number | | important=yes pre | 122 | | Thu 08 Nov 2018 09:26:09 AM CET | root | number | zypp(zypper) | important=yes post | 123 | 122 | Thu 08 Nov 2018 09:27:40 AM CET | root | number | | important=yes pre | 128 | | Mon 12 Nov 2018 08:40:03 AM CET | root | number | zypp(zypper) | important=yes post | 129 | 128 | Mon 12 Nov 2018 08:41:36 AM CET | root | number | | important=yes pre | 144 | | Mon 19 Nov 2018 09:52:15 AM CET | root | number | zypp(zypper) | important=no  post | 145 | 144 | Mon 19 Nov 2018 09:54:33 AM CET | root | number | | important=no  pre | 146 | | Wed 21 Nov 2018 11:07:33 AM CET | root | number | zypp(zypper) | important=no  post | 147 | 146 | Wed 21 Nov 2018 11:07:56 AM CET | root | number | | important=no  pre | 148 | | Thu 22 Nov 2018 09:19:51 AM CET | root | number | zypp(zypper) | important=no  post | 149 | 148 | Thu 22 Nov 2018 09:19:54 AM CET | root | number | | important=no  pre | 150 | | Mon 26 Nov 2018 09:12:02 AM CET | root | number | zypp(zypper) | important=no  post | 151 | 150 | Mon 26 Nov 2018 09:12:19 AM CET | root | number | | important=no  pre | 152 | | Thu 29 Nov 2018 09:34:37 AM CET | root | number | zypp(zypper) | important=no  post | 153 | 152 | Thu 29 Nov 2018 09:35:22 AM CET | root | number | | important=no

Ich habe auch von alten unbenutzten Kerneln gehört, also habe ich es herausgefunden und Folgendes gefunden:

$ ls -la /lib/modules total 0 drwxr-xr-x 1 root root 108 Nov 8 09:29 . drwxr-xr-x 1 root root 78 Oct 4 16:13 .. drwxr-xr-x 1 root root 354 Oct 16 09:11 4.12.14-lp150.12.22-default drwxr-xr-x 1 root root 354 Nov 8 09:26 4.12.14-lp150.12.25-default

Ideen für eine Lösung:

  1. Ändern Sie die Größe der Stammpartition. (Wurzel 10 weitere Gigs zu geben wäre schön)
  2. Wenn Sie die alte Kernel-Version löschen, hoffe ich, dass ich nichts kaputt mache, und die frei gewordenen 245 MB werden jetzt ausreichen.

Ich mag es wirklich, Root mehr Platz zu geben, habe aber keine Ahnung, wie das geht, oder ob es eine gute Idee ist, sich überhaupt damit zu beschäftigen. Welche Lösung würden Sie vorschlagen und wie kann ich das tun?

0

2 Antworten auf die Frage

0
Server Fault

Zuerst müssen Sie etwas Wichtiges sichern. Wenn Sie diesen Weg weitergehen, müssen Sie Dinge tun, die zu Datenverlust führen können. Einige Optionen unten:

  • Kaufen Sie eine neue USB-SATA-Festplatte. Tauschen Sie das USB-SATA-Laufwerk in Ihrem Fall mit Ihrem alten Laufwerk aus. Installieren Sie Linux erneut auf dem neuen SATA-Laufwerk. Wenn Sie auf Ihre alten Dateien zugreifen müssen, schließen Sie das USB-Laufwerk an, und dort sind sie.

  • Wenn Sie mit LVM partitioniert haben (was SuSE wahrscheinlich nicht hat), prüfen Sie, ob Sie lvmresize -L+10G /dev/mapper/whateverIhre Slash-Partition erweitern ( ) können und dann die Größe ( resize2fs /dev/mappper/whatever) ändern . Dies ist die einfachste Lösung.

  • Wenn Sie über harte Partitionen verfügen (z. B. root ist eingeschaltet /dev/sda1), können Sie versuchen, Gparted Live ( https://gparted.org/livecd.php ) und Monkey zu starten, um die Partition zu erweitern. Im Allgemeinen hängt der Erfolg davon ab, wie viel Speicherplatz auf Ihrer Festplatte verbleibt und wie Sie die Partitionierung vorgenommen haben

  • Kaufen Sie eine neue Festplatte. Gleiche Kapazität oder größer. schließen Sie es an und erstellen Sie größere Partitionen (verwenden Sie LVM, wenn möglich). Die erste Partition auf der neuen Festplatte sollte 1G groß sein (kann kleiner sein, nur kurz sein) und ist für die Grub-Kompatibilität vorhanden. Danach booten Sie auf Ihrer alten Festplatte und erstellen Verzeichnisse / mounten die neuen Festplattenpartitionen auf /mnt/new_disk/; Synchronisieren Sie alle alten Partitionen auf der neuen Festplatte. (zB: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...). Nachdem Sie fertig sind, müssen Sie Grub irgendwie auf der neuen Festplatte installieren. Normalerweise mache ich das mit einer Chroot in, /mnt/new_disk/slash/aber es kann entmutigend sein. In der Regel wird grub.cfg über Dinge verwirrt. Es muss einfachere Wege geben, dies zu tun.

0
Kamil Maciorowski

/dev/sda2Gemountet an verschiedenen Mountpunkten (wo Sie verschiedene Inhalte haben sollen) lässt mich glauben, dass Sie Btrfs verwenden. Sie haben auch /.snapshotsgemountet, was das Vorhandensein von Snapper anzeigt . Es ist sehr wahrscheinlich, dass /.snapshotsder Großteil des genutzten Speicherplatzes beansprucht wird.

Beachten Sie, dass Ihre Analyse du -hsx /*nicht /.snapshotsberücksichtigt wurde, da *Glob nicht auf Namen erweitert wird, die mit beginnen ..

Ich habe keine Erfahrung mit Snapper. Ich vermute, es gibt Btrfs-Subvolumes (Shapshots) im Inneren /.snapshots. Der Befehl du -hsx /.snapshotskann sogar 0wegen der verwendeten -xOption zurückkehren. Auf der anderen Seite du -hs /.snapshotswird sich wahrscheinlich ein großer Wert ergeben. Es ist möglicherweise viel größer als die Größe von /dev/sda2(was ist 40GiB), da Sie wahrscheinlich über mehrere Snapshots verfügen, die Speicherplatz gemeinsam nutzen (so funktioniert Btrfs), sie jedoch immer dunoch als separate Dateisysteme betrachten.

Zur weiteren Analyse benötigen Sie Btrfs-spezifische und / oder Snapper-Tools. Ich habe etwas Erfahrung mit Btrfs, aber nicht mit Snapper. Ich kann nicht erkennen, ob Sie Snapper durch manuelle Manipulation der erstellten Snapshots verwechseln können. Möglicherweise ist dies möglich. Aber ich bin sicher, dass Sie Btrfs nicht mit Snapper brechen können. Daher ist der sichere Ansatz, die Situation mit dem zu erledigen, was Snapper bietet, und nicht direkt mit den Btrfs-Tools.

Das bereits erwähnte Tutorial gibt uns Hinweise, was Sie tun können:

  • Alle Momentaufnahmen für die Standardkonfiguration auflisten (root)

    snapper list

  • Snapshots löschen

    Löschen Sie den Schnappschuss 65 für die Standardkonfiguration (Stamm):

    snapper delete 65

Aber auch:

Automatische Snapshots-Bereinigungsmechanismen

Um zu verhindern, dass der Festplattenspeicher voll ist, bereinigt Snapper regelmäßig Snapshots. Standardmäßig ist dieser Zeitraum 1 Tag.

Die automatische Bereinigung von Snapshots kann auf zwei Arten verwaltet werden:

  1. Cron-Scheduler ( /etc/cron.daily/suse.de-snapper).
  2. System-Timer-Scheduler ( snapper-cleanup.timerund snapper-cleanup.serviceSystem-Einheiten).

Standardmäßig wird der Cron-Mechanismus verwendet.

Vielleicht ist bei diesem Bereinigungsmechanismus etwas fehlgeschlagen?

Wie gesagt, ich habe keine Erfahrung mit Snapper, daher kann ich Ihnen nicht weiter helfen. Wenn ich recht habe, wissen Sie jetzt, was Sie untersuchen sollen. Zusammenfassen:

  • Sie haben das /.snapshotsVerzeichnis völlig verpasst. Wahrscheinlich ist es für den Großteil des belegten Speicherplatzes verantwortlich.
  • Btrfs-Snapshots sind wahrscheinlich beteiligt.
  • Snapper ist wahrscheinlich beteiligt.
Hat der Snapper nicht 65 gelöscht, da die Snapper-Liste kein Element mit einer 65 angezeigt hat. Sollte die 65 nicht aufgeführt sein? Human vor 5 Jahren 0
@Human Es ist nur ein Beispiel… Kamil Maciorowski vor 5 Jahren 0

Verwandte Probleme