☰

Volle Festplatte der GCP Compute Engine, Größe des Dateisystems im öffentlichen Image nicht angepasst

tag-icon • tag-icon linux google-cloud-platform google-compute-engine
Volle Festplatte der GCP Compute Engine, Größe des Dateisystems im öffentlichen Image nicht angepasst

Die GCP-VM mit 99,8 % voller Festplatte hat ihre Dateisystemgröße nicht geändert, nachdem die Festplattenkapazität in der Google-Konsole erhöht wurde.

Ich habe eine kleine VM auf GCP, die auf einem öffentlichen Image basiert ubuntu-2004-focal-v20220419. Es gab eine 10 GB große Festplatte mit Root-Partition und Dateisystem. Einige Protokolle belegten 99,8 % der Festplattenkapazität. Ich kann sshdie VM verwenden, weil GCP immer noch SSH-Schlüssel darauf kopieren kann, aber um einen großen Ordner zu erkennen, musste ich eine andere Festplatte verwenden, um temporäre Dateien aufzubewahren:

sudo du -Sh | sort -rh -T /dev/tmp | head -5

anstatt

sudo du -hs * | sort -rh | head -10

Ich habe die Festplattengröße auf 15 GB erhöht (ohne Daten zu entfernen) und die VM neu gestartet. Dokumentationsagt:

Bei VMs mit öffentlichen Images passt Compute Engine die Größe der Root-Partition und des Dateisystems automatisch an, nachdem Sie die Größe der Startdiskette erhöht und die VM neu gestartet haben.

Ich kann jedoch sehen, dass die Größe des Dateisystems nicht geändert wurde

~$ sudo lsblk
sda       8:0    0    15G  0 disk 
├─sda1    8:1    0   9.9G  0 part /
├─sda14   8:14   0     4M  0 part 
└─sda15   8:15   0   106M  0 part /boot/efi

Direkt nach dem Neustart der VM wird im Logs Explorer die folgende Meldung angezeigt:

{
  insertId: "1"
  jsonPayload: {
    @type: "type.googleapis.com/cloud_integrity.IntegrityEvent"
    bootCounter: "13"
    earlyBootReportEvent: {
      actualMeasurements: [8]
      policyEvaluationPassed: false
      policyMeasurements: [3]
    }
  }
  logName: "projects/<vm name>/logs/compute.googleapis.com%2Fshielded_vm_integrity"
  receiveTimestamp: "2022-11-30T09:12:33.141683678Z"
  resource: {2}
  severity: "ERROR"
  timestamp: "2022-11-30T09:12:32.752150154Z"
}

Ich habe die Schritte befolgtwww.jhanley.com und es gibt keine Einträge bezüglich der Größenänderung. Es gibt auch weder expand-root.shSkript noch expand-rootDienst.

Ich frage mich, warum das so ist. Ich habe erwartet, dass zusätzliche 5 GB basierend auf der obigen Dokumentation automatisch zusammengeführt werden sda1. Könnte es sein, dass die Festplatte so voll ist, dass einige GCP-Hintergrundprozesse das Dateisystem nicht in der Größe ändern können?

[EDIT] Ich habe einen Snapshot der Festplatte erstellt und die Größe der Dateifreigabe manuell angepasst. In der Ausgabe der seriellen Schnittstelle kann ich jetzt Folgendes sehen:

Nov 30 11:55:30 <vm name> kernel: [    9.016905] EXT4-fs (sda1): resizing filesystem from 4165883 to 4428027 blocks
Nov 30 11:55:30 <vm name> kernel: [    9.021130] EXT4-fs (sda1): resized filesystem to 4428027

Antwort1

Endlich konnte ich es reparieren. In meinem FallDie Festplatte war zu voll, was das System daran hinderte, Skripte zur Größenänderung des Dateisystems auszuführen.

Nach dem LesenBlogbeitrag von John HanleyMir wurde klar, dass die Größenänderung des Dateisystems nie stattgefunden hat. Ich habe die Größe des Dateisystems und der Partitionen selbst wie beschrieben geändertHier:

sudo parted /dev/sda

und dann habe ich das Dateisystem erweitert:

sudo resize2fs /dev/sda1

Das hätte automatisch passieren sollen, was normalerweise passiert, aber der Vorgang konnte, hauptsächlich aufgrund von Festplattenüberlastung, nicht durchgeführt werden. Nach der manuellen Größenanpassung des Dateisystems und der Anpassung der Festplattenkapazität in GCP sehe ich, dass es jetzt wie vorgesehen funktioniert:

Nov 30 11:55:30 <vm name> kernel: [    9.016905] EXT4-fs (sda1): resizing filesystem from 4165883 to 4428027 blocks
Nov 30 11:55:30 <vm name> kernel: [    9.021130] EXT4-fs (sda1): resized filesystem to 4428027

> lsblk
sda       8:0    0    17G  0 disk 
├─sda1    8:1    0  16.9G  0 part /
├─sda14   8:14   0     4M  0 part 
└─sda15   8:15   0   106M  0 part /boot/efi

> sudo df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4       17G   11G  6.2G  63% /

verwandte Informationen