Rocky Linux LVM 디스크 확장, 왜 명령을 4번 쳐야 할까

발단

가상화 환경에서 Rocky Linux 9 VM의 디스크를 늘렸는데, 게스트 OS에서는 여전히 / 파티션 사용률이 위험 수준이었다. 디스크에 의존하는 서비스가 응답을 멈춘 상태였고, lsblk로 보면 sda는 분명히 새 크기인데 df -h는 옛날 크기 그대로다.

$ lsblk
NAME        SIZE TYPE MOUNTPOINTS
sda         200G disk
├─sda1      600M part /boot/efi
├─sda2        1G part /boot
└─sda3       50G part           ← 여기가 안 따라옴
  ├─rl-root  48G lvm  /
  └─rl-swap   2G lvm  [SWAP]

$ df -h /
Filesystem           Size  Used Avail Use%
/dev/mapper/rl-root   48G   42G  6.0G  88%

가상화 측에서 디스크를 키우면 OS가 알아서 따라오는 줄 알았는데, 그게 아니었다. 명령을 4번 따로 쳐야 했다. 왜 그런지 정리해본다.

디스크의 4 layer 구조

리눅스의 스토리지는 여러 layer가 쌓여 있고, 각 layer는 자기 고유의 메타데이터를 들고 있다. 위 layer가 자기 크기를 알아서 갱신해주지 않는다.

[가상화 디스크]                  ← 하이퍼바이저가 키움
        │
        ▼
[Layer 1: 블록 디바이스]  /dev/sda
        │  · OS가 디스크로 인식하는 raw 크기
        │
        ▼
[Layer 2: Partition]  sda1, sda2, sda3
        │  · GPT 메타데이터에 partition 시작/끝 섹터가 적혀 있음
        │  · 디스크가 커져도 End 섹터는 옛 값 그대로
        │
        ▼
[Layer 3: LVM]  PV → VG → LV
        │  · PV: partition을 LVM 풀에 등록한 메타데이터
        │  · VG: 여러 PV를 합친 추상 풀
        │  · LV: VG에서 잘라낸 가상 디바이스 (마운트 대상)
        │
        ▼
[Layer 4: Filesystem]  XFS / ext4
        │  · inode 테이블, journal, free block bitmap 등
        │  · LV가 커져도 FS 메타데이터는 옛 크기
        │
        ▼
[애플리케이션]

각 layer의 메타데이터는 서로 독립적이다. 디스크를 키워도 partition은 모르고, partition을 키워도 PV는 모르고, PV를 키워도 LV는 모르고, LV가 커져도 파일시스템은 모른다.

그래서 layer 별로 명시적으로 키우는 명령을 쳐야 마지막 FS의 가용량이 늘어난다.

4단계 매핑

Layer 변화 작업 의미 명령

1 → 2	partition의 끝 섹터를 디스크 끝까지 옮김	growpart
2 → 3 (PV)	partition의 새 크기를 PV 메타데이터에 반영	pvresize
3 (LV)	VG의 가용량을 LV에 흡수	lvextend
4	FS 메타데이터를 LV 크기까지 확장	xfs_growfs

순서대로 진행해야 한다. partition이 안 커진 상태에서 pvresize만 치면 옛 크기 그대로 인식되어 다음 단계가 의미를 못 갖는다.

진단부터

작업 전에 어디까지 풀려 있는지 확인. 이 단계가 사실상 가장 중요하다. 어디서 멈췄는지 모르고 명령부터 치면 엉뚱한 결과가 나온다.

# 디스크 → partition → LVM 트리 한눈에 보기
lsblk

# 파일시스템 사용률
df -h

# LVM 상세
sudo pvs   # PSize가 partition 크기와 같으면 PV는 옛 크기
sudo vgs   # VFree가 0 = 확장 여지 없음
sudo lvs   # LV 별 크기

체크포인트:

• lsblk의 디스크가 기대 크기인가? (아니면 가상화 측 hot-add가 OS 인식 안 됨)
• partition이 작게 멈춰 있는가?
• pvs의 PSize가 partition 크기와 같은가?
• vgs의 VFree가 0에 가까운가?
• df -h가 임계치 이상인가?

이 패턴이면 아래 절차로 진행.

4단계 복구

Layer 1 → 2: partition 확장

가장 간단한 방법은 growpart.

# /dev/sda의 3번째 partition을 디스크 끝까지
sudo growpart /dev/sda 3

미설치면:

sudo dnf install -y cloud-utils-growpart

확인:

lsblk
# sda3가 디스크 크기 가까이 커졌어야 함

폐쇄망이라 패키지 설치가 어려우면 parted로도 가능하다. 단, GPT 백업 헤더 보정(Fix) 단계가 추가로 필요하다. 본문 끝의 부록에 정리해둔다.

반응형

Layer 2 → 3: PV 크기 재인식

sudo pvresize /dev/sda3

확인:

sudo pvs
# PSize가 새 partition 크기와 일치, VFree가 늘어난 만큼 잡혀야 함

Layer 3: LV 확장

가용량을 root LV가 전부 흡수하는 가장 흔한 케이스:

sudo lvextend -l +100%FREE /dev/mapper/rl-root

LV path는 sudo lvs로 확인. Rocky 기본은 /dev/mapper/rl-root (VG=rl, LV=root). CentOS 7 같은 경우 /dev/mapper/centos-root일 수 있다.

특정 크기만 늘리고 나머지는 남기려면:

sudo lvextend -L +80G /dev/mapper/rl-root

Layer 4: 파일시스템 확장

여기서 OS / FS 종류에 따라 명령이 갈린다.

XFS (Rocky / RHEL 9 기본):

sudo xfs_growfs /

XFS는 마운트 경로를 인자로 받는다.

ext4 (Ubuntu / Debian 기본):

sudo resize2fs /dev/mapper/rl-root

ext4는 디바이스 경로를 받는다.

FS 종류 확인은 df -hT / 또는 lsblk -f로.

검증

4단계가 다 끝나면:

df -h /                # 사용률이 정상으로 떨어졌는지
lsblk                  # LV와 partition이 디스크 크기까지 도달
sudo vgs               # VFree가 0 가까이 (다 흡수했는지)

의존 서비스가 disk full로 stuck이었다면 보통 자동 회복하지만, 안전하게 재기동하는 게 깔끔하다.

sudo systemctl restart <service-name>
journalctl -u <service-name> --since "5 min ago" | tail -50

정리하며

리눅스를 처음 다룰 때 가장 헷갈렸던 게 "왜 디스크를 키웠는데 OS는 모를까" 였다. 결국 답은 각 layer가 독립된 메타데이터를 가진 추상화 계층이라는 점이다. 디스크 위에 partition, partition 위에 PV, PV 위에 VG, VG 위에 LV, LV 위에 FS — 이 구조를 한 번 그려보면 명령이 4번 필요한 이유가 자연스럽게 납득된다.

LVM이 없는 환경(파티션 위에 바로 XFS)이면 Layer 3가 빠져 3단계로 끝난다. 다만 Rocky / RHEL / CentOS의 기본 설치는 거의 항상 LVM을 거쳐 있어서, 운영 중인 VM이라면 이 4단계 절차를 알아두면 거의 매번 통한다.

---

부록: parted로 partition 확장하기 (폐쇄망용)

growpart를 못 쓰는 환경이라면 parted로도 동일하게 가능하다.

sudo parted /dev/sda

대화형으로 진입한 뒤:

(parted) print

가상화에서 디스크를 키운 직후라면 다음 경고가 뜬다.

Warning: Not all of the space available to /dev/sda appears to be used,
you can fix the GPT to use all of the space (an extra 199229440 blocks)
or continue with the current setting?
Fix/Ignore?

GPT는 디스크 시작과 끝 양쪽에 헤더 사본을 둔다. 가상화에서 디스크를 키워도 백업 헤더는 옛 끝 위치에 남아 있어, GPT가 인식하는 디스크 크기가 옛 크기 그대로다. Fix 입력해서 백업 헤더를 새 끝 위치로 옮긴다.

(parted) resizepart 3 100%
Warning: Partition /dev/sda3 is being used. Are you sure you want to continue?
Yes/No? Yes

(parted) print
(parted) quit

LVM partition은 online 확장이 안전하므로 Yes. 마지막으로 커널에 변경 반영:

sudo partprobe /dev/sda

이후 pvresize → lvextend → xfs_growfs 단계는 동일하다.