☰

GCP Compute Engine полный диск не изменяет размер файловой системы в общедоступном образе

tag-icon • tag-icon linux google-cloud-platform google-compute-engine
GCP Compute Engine полный диск не изменяет размер файловой системы в общедоступном образе

Виртуальная машина GCP с заполненным на 99,8% диском не изменила размер своей файловой системы после увеличения емкости диска в консоли Google.

У меня есть небольшая виртуальная машина на GCP, основанная на публичном образе ubuntu-2004-focal-v20220419. Был диск на 10 ГБ с корневым разделом и файловой системой. Некоторые журналы занимали 99,8% емкости диска. Я могу sshзапустить виртуальную машину, потому что GCP все еще может копировать на нее ключи ssh, но для обнаружения большой папки мне пришлось использовать другой диск для хранения временных файлов:

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

вместо

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

Я увеличил размер диска до 15 ГБ (не удаляя никаких данных) и перезапустил виртуальную машину. Документацияговорит:

Для виртуальных машин с публичными образами Compute Engine автоматически изменяет размер корневого раздела и файловой системы после увеличения размера загрузочного диска и перезапуска виртуальной машины.

Однако я вижу, что размер файловой системы не был изменен.

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

Сразу после перезапуска виртуальной машины я вижу следующее сообщение в 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"
}

Я следовал шагам наjhanley.comи нет записей об изменении размера. Также нет ни expand-root.shскрипта, ни expand-rootсервиса.

Мне интересно, почему так? Я ожидал, что дополнительные 5 ГБ будут sda1автоматически объединены на основе вышеуказанной документации. Может ли быть, что диск настолько заполнен, что некоторые фоновые процессы GCP не могут изменить размер файловой системы?

[EDIT] Я создал снимок диска и вручную изменил размер общего файлового ресурса. В выводе последовательного порта я теперь вижу:

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

решение1

Наконец-то мне удалось это исправить. В моем случаедиск был переполнен, что не позволило системе запустить скрипты изменения размера файловой системы.

После прочтенияЗапись в блоге Джона ХэнлиЯ понял, что изменение размера файловой системы никогда не происходило. Я изменил размер файловой системы и разделов самостоятельно, как описаноздесь:

sudo parted /dev/sda

а затем я расширил файловую систему:

sudo resize2fs /dev/sda1

Это должно было быть сделано автоматически, как это обычно и происходит, но опять же, из-за засорения диска, процесс не удалось выполнить. После ручного изменения размера файловой системы и изменения размера емкости диска в GCP я вижу, что теперь все работает так, как и должно:

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

Связанный контент