Erweitern Sie die /var-Partition auf Centos Stream 8

Erweitern Sie die /var-Partition auf Centos Stream 8

Während der Installation meines CentOS Stream 8-Betriebssystems habe ich /var eine Größe von 10 GB zugewiesen, weil ich dachte, das wäre mehr als ausreichend. Als ich jedoch mit der Verwendung von Docker begann, stellte ich fest, dass es zu viel Platz auf der /var-Partition einnimmt, wie der Befehl df zeigt:

[root@compute-07 ~]# df -h
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs              28G     0   28G   0% /dev
tmpfs                 28G     0   28G   0% /dev/shm
tmpfs                 28G  179M   28G   1% /run
tmpfs                 28G     0   28G   0% /sys/fs/cgroup
/dev/mapper/cs-root  371G  8.2G  363G   3% /
/dev/mapper/cs-home  100G  2.0G   98G   2% /home
/dev/mapper/cs-var    10G  9.0G  1.1G  90% /var
/dev/sda2            2.0G  412M  1.6G  21% /boot
/dev/sda1            2.0G  7.3M  2.0G   1% /boot/efi
/dev/mapper/cs-tmp    10G  105M  9.9G   2% /tmp
tmpfs                5.5G   16K  5.5G   1% /run/user/42
overlay               10G  9.0G  1.1G  90% 

/var/lib/docker/overlay2/77f74478297ca61595f0003d35c7323ec627adb44d94cef92c2b4a3c97319a66/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/5eeb399ce4a3c0d8065d63123985269a359fa66f4d20a8486326e466a48a0128/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/08d42ca66e3a5974bc305b502bca2aa4d22aa7ddcab6ea14c6af300b3abb3a70/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/1a45cb32b127fdf8f5c1483385139a865fdc69260ec20f3dcd4c56ad6890f909/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/ebb9af8edee824a4013dcd526e33e22272283bdee508fd43208fade557def728/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/41d55822108d04c85f348dc134fe6929b0e67f6b3bd7e0af147633bfd3a252c1/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/5cf3e8e06e9b4c2e6ed65164d91aed19f63d55e91524d6563e9f16b6709d29be/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/1d1eda94e68596b00d0cabcc75a7c91999a1c845ebd02c733bb9f00ac66a26f0/merged
overlay               10G  9.0G  1.1G  90% /var/lib/docker/overlay2/bc9e9a28c6761ad89a9457110642156ebd2b4d77de841f2a3ac9ffbaa90e4b63/merged

tmpfs                5.5G     0  5.5G   0% /run/user/0

Dies ist die Ausgabe des Befehls lsblk, da /var sich in einer separaten Partition befindet, dann / und /home. Ich konnte keine Möglichkeit finden, die Größe zu ändern oder eine andere Partition zu erstellen und sie dann mit /var zu verknüpfen

[root@compute-07 ~]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0 558.4G  0 disk 
├─sda1        8:1    0     2G  0 part /boot/efi
├─sda2        8:2    0     2G  0 part /boot
└─sda3        8:3    0 554.4G  0 part 
  ├─cs-root 253:0    0 370.4G  0 lvm  /
  ├─cs-swap 253:1    0    64G  0 lvm  [SWAP]
  ├─cs-tmp  253:2    0    10G  0 lvm  /tmp
  ├─cs-home 253:3    0   100G  0 lvm  /home
  └─cs-var  253:4    0    10G  0 lvm  /var
sr0          11:0    1  1024M  0 rom  

Gibt es eine Möglichkeit, die Größe dieser Partition zu ändern, ohne Daten zu verlieren?

Antwort1

Nein. Tatsächlich wird der meiste Platz im System immer dort genutzt, /varwo normalerweisevariable Daten leben — Datenbanken, Docker, Protokolle und so weiter, während Linux's /,seltenbenötigt mehr als 10 GiB Speicherplatz, wenn das System ordnungsgemäß verwaltet wird.

Nicht nur Ihr LVM ist nicht optimal: Ich würde die gesamte Debian-Installation mit einigen Diensten in den Speicherplatz packen, den Sie in Ihrem ESP und verschwendet haben /boot. (Ich hatte die Angewohnheit, VMs mit 4 GiB zu erstellen, die dem System zugewiesen waren. Mehr als genug.)

Die beste Lösung wäre also, Ihr überdimensioniertes Root-Dateisystem zu verkleinern, aber das geht nicht online. Sie müssen ein Rettungsmedium booten, Ihre VG aktivieren und dann das Dateisystem und das logische Volume verkleinern, was angesichts der Größe der Partition sehr viel Zeit in Anspruch nehmen kann. Außerdem kann man dabei auch etwas durcheinanderbringen. Wenn Sie es eilig haben, können Sie es auch anders machen: Erstellen Sie ein Verzeichnis im Root-Verzeichnis, verschieben Sie die Docker-Daten hinein und mounten Sie es per Bind-Mount wieder dort, wo die Docker-Daten in var gespeichert sind. Sie müssen Docker und alle Container vorerst stoppen. Etwa so:

systemctl stop docker.service
mkdir /var-lib-docker
mv /var/lib/docker/* /var-lib-docker
mount --bind /var-lib-docker /var/lib/docker
systemctl start docker.service

Auf diese Weise nutzt der Docker den Platz auf dem überdimensionierten Root-Dateisystem, ist aber am gewohnten Speicherort verfügbar. Damit /etc/fstabdiese Konfiguration den Neustart übersteht, müssen Sie den folgenden Eintrag hinzufügen:

/var-lib-docker /var/lib/docker none bind 0 0

Bedenken Sie jedoch, dass es sich hierbei um einen ziemlich hässlichen Hack handelt, der Ihnen zwar etwas Zeit verschafft, aber auch einige Probleme mit sich bringt. Suchen Sie daher nach einer Möglichkeit, Speicherplatz vom Stammverzeichnis zurückzufordern und ihn /varordnungsgemäß zuzuordnen.

Und daraus sollten Sie lernen: Weisen Sie nie von Anfang an allen verfügbaren Speicherplatz zu. Lassen Sie einen Teil (den größten Teil) davon unzugewiesen. Sie können den Speicherplatz jederzeit problemlos online hinzufügen, während es sehr schwierig, zeitaufwändig und fehleranfällig ist, ihn zurückzufordern, und dies erfordert Ausfallzeiten. Am besten verwalten Sie den Speicherplatz so, dass Sie ihn nie zurückfordern müssen.

Antwort2

Als Alternative zudiese Antwort

Ihr System verwendet logische LVM-Volumes.

Möglicherweise ist in der Datenträgergruppe noch etwas ungenutzter Speicherplatz übrig, den Sie der Erweiterungsvariable zuweisen können.

Falls kein oder zu wenig ungenutzter Platz mehr vorhanden ist, können SieReduzieren oder entfernen Sie den Swap-LVMund nutzen Sie den dadurch freigegebenen Platz, um /var zu erweitern.

Dadurch bleibt Ihr System intakt und die Aktion kann normalerweise sogar online durchgeführt werden.

Der Ansatz hierfür wäre etwa: (Befehle ungetestet, also nicht direkt kopieren, aber das Prinzip sollte stimmen)

  • Erstellen Sie als Ersatz eine temporäre oder permanente Auslagerungsdatei auf Ihrem übergroßen Root-Dateisystem, während Sie die Auslagerungspartition offline nehmen.

    • dd if=/dev/zero of=/swap-file count=65536 bs=1M
    • mkswap /swap-file
    • swapon /swap-file
  • swapoff /dev/mapper/cs-swap um die Swap-Partition zu deaktivieren

  • lvreducecs-swap, gefolgt von der erneuten Formatierung der verbleibenden LVM-Swap-Partition mit mkswapund der erneuten Aktivierung des kleineren Swap-Speichers mitswapon

  • oder löschen Sie es direkt mitlvremove

Verwenden Sie den neu erstellten freien LVM-Speicherplatz, um das /var LVM-Volume zu erweitern und das Dateisystem zu erweitern

lvextend -l +100%FREE --resizefs /dev/mapper/cs-var

Antwort3

Sie dfund lsblksagen Sie uns nicht, was ihre Dateisysteme sind. Um ein Volume (Partition oder LV) zu verkleinern, muss zuerst das darauf befindliche Dateisystem verkleinert werden. Eine häufige Wahl für Root-FS, ext4, kann offline verkleinert werden. Die Standard-FS-Wahl für CentOS (und RHEL-ähnliche Distributionen) ist jedoch XFS und kann derzeit nicht verkleinert werden.

Wie andere in ihren Antworten bereits erwähnt haben, ist es nicht schwierig, Ihre RootFS-Nutzung von 8,2 GB zu sichern. Abhängig von Ihrem RootFS-Dateisystemtyp haben Sie also die folgenden Optionen:

Wenn es ext4 ist, können Sie es vor Ort verkleinern:

  • Führen Sie einen Neustart auf einem anderen System durch, beispielsweise einem ArchISO, da ext4 nur offline verkleinert werden kann.

  • Stellen Sie sicher, lvsdass Ihre Partition angezeigt wird, danne2fsck -f /dev/mapper/cs-root

  • resize2fs -M -p /dev/mapper/cs-root

    • Wenn Sie die gewünschte Root-Dateigröße kennen, können Sie diese alternativ angeben, anstatt Folgendes zu verwenden -M:

      resize2fs -p /dev/mapper/cs-root 15G

      Beachten Sie, dass es besser ist, etwas Platz zum Verkleinern des darunter liegenden Volumens zu lassen.

  • Speicherplatz vom LV zurückgewinnenlvreduce -L 16G cs/root

  • Passen Sie die Größe des Dateisystems wieder an die Datenträgergröße an:resize2fs -p /dev/mapper/cs-root

  • Nun kann der freie Speicherplatz vergeben werden an /var:lvextend -l +100%FREE cs/var

Wenn es sich jedoch um XFS handelt, sichern Sie am besten Ihr Root-FS und erstellen es neu:

  • Starten Sie ein ArchISO wie oben.
  • rsync -avHAXx /your-rootfs /somewhere(Stellen Sie sicher, /somewheredass es sich auf einem anderen Datenträger befindet. 8,2 GB freier Speicherplatz sind leicht zu finden. Ihr Swap-Datenträger ist höchstwahrscheinlich überdimensioniert.)
  • lvremovedas Stammvolume und erstellen Sie es mit einer geeigneten Größe neu. Ich empfehle diesmal die Formatierung auf ext4.
  • rsync -avHAXx /somewhere /your-rootfsum Dinge zurückzukopieren.
  • Aktualisieren Sie bei Bedarf Ihre GRUB-Konfiguration – soweit ich weiß, wird die LV-ID oft als Hinweis hineingeschrieben grub.cfg, aber ich kenne mich mit CentOS nicht aus (unter Debian wäre es einfach update-grub).
  • Weisen Sie freien Speicherplatz im VG wie oben beschrieben zu.

Weitere Anmerkungen, auf die ich hinweisen möchte:

  • Ihre EFI-Systempartition (ESP) ist zu groß. Für einen typischen Linux-Server sollten 256 MB mehr als ausreichend sein (ich verwende 128 MB auf meinem Ubuntu-Server). Sie muss nur die GRUB-Binärdatei und eine sehr einfache Version von enthalten grub.cfg.
  • /bootmuss nicht auf einem eigenen Datenträger laufen. GRUB kann LVM und Ihr RootFS-Dateisystem problemlos lesen.
  • Abhängig von Ihrem Serverdesign /rootist Ihr Server wahrscheinlich auch überdimensioniert (ich verwende 16 GB für meinen Proxmox VE-Server – ich plane nicht, Daten auf dem Host zu speichern).
  • Brauchen Sie wirklich 64 GB Swap-Speicher? Normalerweise reichen mir 8 GB.

verwandte Informationen