Как расширить раздел диска при общем размере 100 ГБ и 40 ГБ в корне?

Что проверяют

Умеете ли вы увеличить корневой раздел на живой системе без переустановки и потери данных, и различаете ли раздел, том LVM и файловую систему. Следом обычно спрашивают, что делать, если свободное место лежит не сразу за корневым разделом.

Как отвечать

Сначала диагностика. Одного df -h мало, он показывает только смонтированные файловые системы:

• lsblk и df -hT: где лежат 60 ГБ свободного места, есть ли LVM и какая файловая система, ext4 или XFS;
• vgs: если корень на LVM, свободное место может быть уже в группе томов. На Ubuntu Server после установки по умолчанию это частая картина.

Дальше три слоя, каждый расширяется своей командой:

• раздел: growpart /dev/sda 3 из пакета cloud-guest-utils или parted с resizepart. Сработает, если свободное место идёт сразу за разделом;
• LVM: pvresize /dev/sda3, затем lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv. Ключ -r сразу расширяет и файловую систему;
• файловая система: для ext4 resize2fs на устройство, для XFS xfs_growfs /, то есть на точку монтирования. Обе растут онлайн, отмонтировать корень не нужно.

В облаке порядок такой: снимок диска, увеличение диска в консоли, затем ядро должно увидеть новый размер (обычно видит само, иначе rescan устройства или перезагрузка). Часто cloud-init сам растягивает корень при загрузке.

Если между корнем и свободным местом стоит другой раздел, например swap, варианты такие: удалить swap и пересоздать его в конце диска, добавить новый раздел как PV в ту же группу LVM или смонтировать его отдельно под /var или данные.

Где спотыкаются

Растягивают раздел и забывают про файловую систему. lsblk показывает 100 ГБ, а df по-прежнему 40.

Запускают fsck на смонтированном корне «для проверки». Сам e2fsck об этом предупреждает: исправления на смонтированной файловой системе могут её повредить.

Не делают снимок перед parted. Ошибка в номере раздела или конечном секторе стоит всех данных, а снимок в облаке делается за минуту.