☰

Problem

tag-icon • tag-icon linux partitioning filesystems root opensuse
Problem

Problem

Offenbar geht mir der Speicherplatz auf meiner Root-Partition aus. Als ich mein Betriebssystem installierte (openSUSE Leap 15 auf einer VM), wählte ich die Standardpartitionierung. Jetzt erhalte ich die Warnung/FehlermeldungWenig Speicherplatz auf der „Dateisystem-Root“. Es warnt mich, wenn ich das System starte, und wenn ich versuche, ein großes Projekt zu kompilieren, tritt ein Fehler auf.

Analyse

Schauen wir uns die Speichersituation an:

Bericht zur Speicherplatznutzung des Dateisystems:

$ 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ätzen Sie die Dateispeicherplatznutzung:

$ 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

Auflisten von Schnappschüssen, 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, habe sie mir angesehen 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

Lösungsideen:

  1. Größe der Root-Partition ändern. (Root 10 GB mehr zu geben wäre nett)
  2. Ich lösche die alte Kernel-Version und hoffe, dass ich nichts kaputt mache. Die freigegebenen 245 MB werden fürs Erste ausreichen.

Ich bin wirklich dafür, Root einfach mehr Platz zu geben, habe aber keine Ahnung, wie das geht oder ob es überhaupt eine gute Idee ist, damit herumzuspielen. Welche Lösung würden Sie vorschlagen und wie kann ich das tun?

Antwort1

/dev/sda2an verschiedenen Mountpunkten gemountet (wo Sie unterschiedliche Inhalte haben sollten) lässt mich glauben, dass Sie Btrfs verwenden. Sie haben auch /.snapshotsgemountet, was auf die Anwesenheit von hinweistSchnapper. Es ist sehr wahrscheinlich, dass dies /.snapshotsden größten Teil des genutzten Speicherplatzes einnimmt.

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

Ich habe keine Erfahrung mit Snapper. Ich vermute, dass sich darin Btrfs-Subvolumes (Shapshots) befinden /.snapshots. Der Befehl du -hsx /.snapshotskann 0aufgrund der -xverwendeten Option sogar zurückkehren. Andererseits du -hs /.snapshotswird wahrscheinlich ein riesiger Wert zurückgegeben. Er kann viel größer sein als die Größe von /dev/sda2(was ist 40GiB), weil Sie wahrscheinlich mehrere Snapshots haben, die sich Speicherplatz teilen (so funktioniert Btrfs), dusie aber trotzdem als separate Dateisysteme betrachten werden.

Für eine weitere Analyse benötigen Sie Btrfs-spezifische und/oder Snapper-Tools. Ich habe einige Erfahrung mit Btrfs, aber nicht mit Snapper. Ich kann nicht sagen, ob Sie Snapper durch manuelles Verstümmeln der erstellten Snapshots verwirren können. Das ist vielleicht möglich, aber ich bin sicher, dass Sie Btrfs mit Snapper nicht beschädigen können. Daher ist es am sichersten, die Situation mit dem zu handhaben, was Snapper bietet, und nicht direkt mit Btrfs-Tools.

Das bereits erwähnte Tutorialgibt uns einige Hinweise, was Sie tun können:

  • Alle Snapshots für die Standardkonfiguration (Root) auflisten

    snapper list

  • Löschen von Snapshots

    Löschen Sie Snapshot 65 für die Standardkonfiguration (Root):

    snapper delete 65

Aber auch:

Automatische Snapshot-Bereinigungsmechanismen

Um zu verhindern, dass der Speicherplatz voll wird, bereinigt Snapper regelmäßig Snapshots. Standardmäßig beträgt 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. systemd-Timer-Scheduler ( snapper-cleanup.timerund snapper-cleanup.servicesystemd-Einheiten).

Standardmäßig wird der Cron-Mechanismus verwendet.

Vielleicht ist bei diesem Bereinigungsmechanismus etwas fehlgeschlagen?

Wie gesagt, ich habe keine Erfahrung mit Snapper und kann Ihnen daher nicht weiterhelfen. Wenn ich jedoch Recht habe, wissen Sie jetzt, was Sie untersuchen müssen. Zusammenfassend:

  • Sie haben das Verzeichnis völlig übersehen /.snapshots; höchstwahrscheinlich ist es für den Großteil des belegten Speicherplatzes verantwortlich.
  • Wahrscheinlich handelt es sich um Btrfs-Snapshots;
  • Wahrscheinlich ist Snapper beteiligt.

Antwort2

Als Erstes sollten Sie eine Sicherungskopie aller wichtigen Daten erstellen. Wenn Sie diesen Weg weiterverfolgen, können Dinge passieren, die zu Datenverlust führen können. Nachfolgend einige Optionen:

  • Kaufen Sie eine neue USB-SATA-Festplatte. Tauschen Sie das USB-SATA-Laufwerk gegen Ihr altes Laufwerk in Ihrem Gehäuse 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 schon sind sie da.

  • Wenn Sie mit LVM partitioniert haben (was SuSE wahrscheinlich nicht getan hat), versuchen Sie, lvmresize -L+10G /dev/mapper/whateverIhre Slash-Partition zu erweitern () und dann die Größe anzupassen ( resize2fs /dev/mappper/whatever). Das ist die einfachste Lösung.

  • Wenn Sie harte Partitionen haben (z. B.: root ist auf /dev/sda1), können Sie versuchen, mit Gparted Live zu booten (https://gparted.org/livecd.php) und versuchen Sie, Ihre Festplattenpartition zu erweitern. Im Allgemeinen hängt der Erfolg hier davon ab, wie viel freier Speicherplatz auf Ihrem Laufwerk übrig ist und wie Sie die Dinge partitioniert haben

  • Kaufen Sie eine neue Festplatte. Gleiche oder größere Kapazität. Schließen Sie sie an und erstellen Sie größere Partitionen (verwenden Sie wenn möglich LVM). Die erste Partition auf der neuen Festplatte sollte 1 GB groß sein (kann auch kleiner sein, nur um es kurz zu machen) und dient der Kompatibilität mit Grub. Booten Sie anschließend Ihre alte Festplatte und erstellen Sie Verzeichnisse/mounten Sie die neuen Festplattenpartitionen darauf /mnt/new_disk/; synchronisieren Sie alle alten Partitionen per Rsync auf der neuen Festplatte. (z. B.: rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...). Wenn Sie fertig sind, müssen Sie Grub irgendwie auf der neuen Festplatte installieren. Normalerweise mache ich das mit einem Chroot-Zugriff, /mnt/new_disk/slash/aber das kann entmutigend sein. Normalerweise gerät grub.cfg durcheinander. Es muss einfachere Wege geben, das zu tun.

verwandte Informationen