El disco completo de GCP Compute Engine no ha cambiado de tamaño en la imagen pública

El disco completo de GCP Compute Engine no ha cambiado de tamaño en la imagen pública

La máquina virtual de GCP con un disco lleno al 99,8 % no ha cambiado el tamaño de su sistema de archivos después de aumentar la capacidad del disco en la consola de Google.

Tengo una pequeña máquina virtual en GCP basada en una imagen pública ubuntu-2004-focal-v20220419. Había un disco de 10 GB con partición raíz y sistema de archivos. Algunos registros ocuparon el 99,8% de la capacidad del disco. Puedo usar sshla VM porque GCP aún puede copiarle claves ssh, pero para detectar una carpeta pesada tuve que usar otro disco para guardar archivos temporales:

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

en lugar de

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

Aumenté el tamaño del disco a 15 GB (sin eliminar ningún dato) y reinicié la VM. Documentacióndice:

Para las máquinas virtuales con imágenes públicas, Compute Engine cambia automáticamente el tamaño de la partición raíz y el sistema de archivos después de aumentar el tamaño del disco de arranque y reiniciar la máquina virtual.

sin embargo, puedo ver que no se cambió el tamaño del sistema de archivos

~$ 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

Inmediatamente después de reiniciar la VM, puedo ver el siguiente mensaje en Logs Explorer:

{
  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"
}

Seguí los pasosjhanley.comy no hay entradas sobre el cambio de tamaño. Tampoco hay expand-root.shguión ni expand-rootservicio.

Me pregunto ¿por qué es así? Esperaba que se fusionaran 5 GB adicionales sda1automáticamente según la documentación anterior. ¿Podría ser que el disco esté tan lleno que algunos procesos en segundo plano de GCP no puedan cambiar el tamaño del sistema de archivos?

[EDITAR] Creé una instantánea del disco y cambié el tamaño del archivo compartido manualmente. En la salida del puerto serie ahora puedo ver:

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

Respuesta1

Finalmente pude arreglarlo. En mi casoel disco estaba demasiado lleno, lo que impidió que el sistema ejecutara scripts de cambio de tamaño del sistema de archivos.

Despues de leerPublicación del blog de John HanleyMe di cuenta de que el cambio de tamaño del sistema de archivos nunca había ocurrido. Cambié el tamaño del sistema de archivos y las particiones como se describeaquí:

sudo parted /dev/sda

y luego amplié el sistema de archivos:

sudo resize2fs /dev/sda1

Eso debería haberse hecho automáticamente, lo que sucede normalmente, pero nuevamente, debido principalmente a la obstrucción del disco, el proceso no se pudo realizar. Después de cambiar manualmente el tamaño del sistema de archivos y cambiar el tamaño de la capacidad del disco en GCP, veo que ahora funciona como se supone:

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% /

información relacionada