☰

O disco completo do GCP Compute Engine não foi redimensionado no sistema de arquivos na imagem pública

tag-icon • tag-icon linux google-cloud-platform google-compute-engine
O disco completo do GCP Compute Engine não foi redimensionado no sistema de arquivos na imagem pública

A VM do GCP com 99,8% de disco cheio não redimensionou seu sistema de arquivos após aumentar a capacidade do disco no console do Google.

Eu tenho uma pequena VM no GCP baseada em public image ubuntu-2004-focal-v20220419. Havia um disco de 10 GB com partição raiz e sistema de arquivos. Alguns logs ocuparam 99,8% da capacidade do disco. Consigo usar ssha VM porque o GCP ainda pode copiar chaves ssh para ela, mas para detectar uma pasta pesada tive que usar outro disco para manter os arquivos temporários:

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

em vez de

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

Aumentei o tamanho do disco para 15 GB (sem remover nenhum dado) e reiniciei a VM. Documentaçãodiz:

Para VMs com imagens públicas, o Compute Engine redimensiona automaticamente a partição raiz e o sistema de arquivos depois que você aumenta o tamanho do disco de inicialização e reinicia a VM.

no entanto, posso ver que o sistema de arquivos não foi redimensionado

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

Logo após reiniciar a VM posso ver a seguinte mensagem no 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"
}

Eu segui os passos emjhanley. come não há entradas sobre redimensionamento. Também não há expand-root.shscript nem expand-rootserviço.

Eu estou me perguntando por que isso acontece? Eu esperava que 5 GB adicionais fossem mesclados sda1automaticamente com base na documentação acima. Será que o disco está tão cheio que alguns processos em segundo plano do GCP não conseguem redimensionar o sistema de arquivos?

[EDITAR] Criei um instantâneo do disco e redimensionei o compartilhamento de arquivos manualmente. Na saída da porta serial agora posso 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

Responder1

Finalmente consegui consertar. No meu casoo disco estava muito cheio, o que impediu o sistema de executar scripts de redimensionamento do sistema de arquivos.

Depois de lerPostagem do blog de John HanleyPercebi que o redimensionamento do sistema de arquivos nunca aconteceu. Eu mesmo redimensionei o sistema de arquivos e as partições conforme descritoaqui:

sudo parted /dev/sda

e então estendi o sistema de arquivos:

sudo resize2fs /dev/sda1

Isso deveria ter sido feito automaticamente, o que normalmente acontece, mas novamente, principalmente devido ao entupimento do disco, o processo não pôde ser executado. Após redimensionar manualmente o sistema de arquivos e redimensionar a capacidade do disco no GCP, vejo que agora funciona como deveria:

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

informação relacionada