내가 도저히 부팅무터 마운트까지… 여러 세부 과정들이 이해가 되지 않아 매우 쉬운 비유와 함께 정리한 글이다.
- 해당 정리글에서는 MBR을 통한 파티셔닝만으로 설명을 합니다.
- 최근에는 GPT 방식 또한 많이 사용됩니다.
Ch.1 파티션 생성
"디스크를 큰 땅이라고 비유한다. 이 땅에 수영장을 만들 계획이다. 먼저 땅의 어느 부분을 사용할지 구역을 나눠야 한다.”
fdisk /dev/sdb
파티셔닝은 곧, 매우 큰 디스크라는 땅에 경계선을 긋는 작업이라고 볼 수 있다.
- 아직 아무것도 없는 빈 땅에 "여기서 여기까지는 1번 구역"이라고 표시하는 거다.
- 아직 아무것도 없다니?
- → 아직까지 물리 디스크만 존재하고 우리가 설정해준 것이 아무것도 없다.
그럼 실제 fdisk가 하는 일은 뭘까?
- 디스크 맨 앞(섹터 0)의 MBR을 읽는다.
- 사용자가 지정한 파티션 정보를 MBR 파티션 테이블에 기록한다.
- 시작 위치: 2048 섹터
- 크기: 10GB
- 타입: 0x8E (Linux LVM)
- MBR을 디스크에 저장
위와 같은 과정을 겪으면 큰 땅(디스크)은 아래와 같이 되어 있을 거다.

중요한 것은 파티션을 만들었다고 실제로 디스크에 벽이 생기는 것이 아니다.
- MBR이라는 안내판에 1번 구역은 여기서부터 여기까지다. 라고 적어놓는 것뿐이다.
Ch.2 PV 생성
"나눠놓은 땅에 물탱크를 설치한다. 이 물탱크가 나중에 수영장의 물 공급원이 된다.”
pvcreate /dev/sdb1
첫번째 일은 바로 파티션을 LVM이 관리할 수 있도록 등록하는 작업이다.
- "파티션에 '여기에 물탱크 설치됨'이라는 표시를 하고, 물탱크 내부를 일정한 크기(PE)로 나눠서 관리하기 쉽게 만든다.”
- 물탱크의 IN/OUT 통로가 좀 많겠지?
pvcreate는 뭘 하는데?
- /dev/sdb1의 맨 앞에 LVM Label 기록
- 이 파티션은 이제 LVM PV 입니다.
- 메타데이터 영역 생성
- PV의 고유 ID, 크기, PE 정보 등 저장
- 나머지 공간을 PE(Physical Extent)로 분할
- 기본 4MB 크기 블록으로 나눈다.
파티션 내부(/dev/sdb1)는 이렇게 변할 것이다.

PE는 뭔데?
Physical Extent의 약자로, LVM이 공간을 관리하는 최소 단위다.
비유하자면, 파티션 위에 설치한 물탱크(PV) 내부를 일정한 블록으로 잘라놓고, 해당 단위로 꺼내서 쓰는 것이다.
- PE 크기: 기본 4MB (변경 가능)
- 10GB 파티션 → 약 2560개의 PE로 분할
Ch.3 VG 생성
"여러 물탱크를 파이프로 연결해서 하나의 큰 수영장을 만든다.”
여러 PV들이 있을 것이다. 그 넓은 땅을 어떻게 하나의 파티션으로만 관리하겠는가?
이제 여러 PV의 PE들을 하나의 풀(Pool)로 묶는 작업을 한다.
- "여러 물탱크(PV)의 물을 합쳐서 하나의 큰 수영장(VG)으로 만드는 것이다. 물이 어느 탱크에서 왔는지 상관없이 자유롭게 사용할 수 있다.”
vgcreate my_vg /dev/sdb1
vgcreate는 무슨 일을 하는데?
- VG 메타데이터 생성
- VG 이름: my_vg
- VG 고유 ID
- 소속된 PV 목록
- 총 PE 개수, 사용 가능 PE 개수
- 이 메타데이터를 각 PV에 복사 저장
- 나중에 복구할 때 유용하다.
VG의 내부 상태는 아래와 같이 구성된다.

여러개의 PV를 묶는다면?
# 나중에 디스크를 추가할 때
pvcreate /dev/sdb1
vgextend my_vg /dev/sdb1
# VG: my_vg (확장 후) -> 아래 이미지 참고

이때 묶고, 다루는 방법에 대해 여러 방법이 존재한다.
- 스트라이프, 미러, RAID-x 등에 대해서는 추후 정리할 예정이다.
Ch.4 LV 생성
"수영장 안에 구역을 나누는 과정이다. (예: 레인 수영 구역, 자유 수영 구역)”
VG의 PE 풀에서 필요한 만큼 PE를 꺼내서 하나의 논리적 공간(LV)를 만드는 작업이다.
- "수영장 전체 공간에서 필요한 만큼 떼어내서 특정 용도의 구역(LV)을 만드는 거다.”
lvcreate -L 10G -n home_lv my_vg
lvcreate가 하는 일은 아래와 같다.
- 필요한 PE 개수 계산 10GB ÷ 4MB = 2,560개 PE 필요
- VG의 Free PE에서 2,560개 할당
- LE ↔ PE 매핑 테이블 생성
- /dev/my_vg/home_lv 디바이스 생성
VG 상태 변화
- Before: Free PE 2,560개
- After: Free PE 0개, Used PE 2,560개 (home_lv가 사용)
LE는 또 뭔데…
Logical Extent의 약자로, LV 관점에서 본 블록이다.
- PE vs LE
- PE = 물리적 위치 (어느 디스크의 몇 번 블록)
- LE = 논리적 위치 (LV의 몇 번째 블록)
- 매핑 예시
- home_lv
- LE 0 → /dev/sda1의 PE 0
- LE 1 → /dev/sda1의 PE 1
- LE 2 → /dev/sdb1의 PE 0 ← 다른 디스크
- home_lv
- LV를 사용하는 입장에선 LE 0, 1, 2가 연속으로 보이지만
- 실제 PE는 여러 디스크에 흩어져 있을 수 있다.
Ch.5 파일 시스템 생성
LV라는 빈 공간에 파일과 디렉토리를 저장할 수 있는 구조를 만드는 과정이다. "수영장 구역에 실제 시설(레인, 사다리, 배수구 등)을 설치하는 거다. 이 시설이 있어야 사람들이 수영장을 제대로 이용할 수 있다.”
mkfs.ext4 /dev/my_vg/home_lv
mkfs.ext4가 하는 일
- LV 공간에 ext4 파일시스템 구조 생성
- 슈퍼블록: 파일시스템 전체 정보
- inode 테이블: 파일 메타데이터 저장소
- 데이터 블록 영역: 실제 파일 내용 저장소
- 저널 영역: 갑자기 꺼져도 복구할 수 있도록
- /dev/my_vg/home_lv 내부

왜 이 단계가 필요한가?
- LV는 그냥 빈 공간일 뿐이다. 파일을 저장하려면 "파일 이름은 어디에 기록하고, 내용은 어디에 저장하고..." 같은 **체계(=시스템)**가 필요하다. 이 시스템을 ‘파일 시스템’이라고 한다.
단! xfs는 '축소'가 불가능하다. (인지 하기)
Ch.6 마운트
"수영장 구역을 개방해서 사람들이 이용할 수 있게 하는 거다. '/home'이라는 입구 표지판을 달아주는 것과 같다.”
파일시스템을 디렉토리 트리에 연결하는 작업이다. 건물에 주소를 붙여서 입주하는 거다.
mount /dev/my_vg/home_lv /home
mount가 하는 일은 아래와 같다.
- /dev/my_vg/home_lv의 파일시스템 타입 확인 (ext4)
- ext4 드라이버 로드
- 슈퍼블록 읽어서 파일시스템 정보 파악
- /home 디렉토리와 연결
마운트 전/후
- 전: /home → (빈 디렉토리이거나 기존 내용)
- 후: /home → /dev/my_vg/home_lv의 파일시스템 루트
마운트의 효과
마운트 후 파일 접근 흐름:
사용자: /home/user/file.txt 열어줘
↓
커널: /home은 home_lv에 마운트되어 있네
↓
ext4: user/file.txt의 inode 찾고, 데이터 블록 위치 확인
↓
LVM: 해당 위치는 LE 100번 → PE 매핑 조회 → /dev/sda1의 PE 100
↓
디스크: 실제 섹터에서 데이터 읽기
etc.1 확장 시나리오
만약 /home이 다 찾을 때 10GB → 20GB로 늘리는 방법
VG에 여유 공간이 있는 경우
# 1. VG 상태 확인
vgdisplay my_vg
출력 예시:
VG Name my_vg
Free PE / Size 2560 / 10.00 GiB ← 여유 공간 있다.
# 2. LV 확장 (PE 풀에서 더 가져옴)
lvextend -L +10G /dev/my_vg/home_lv
변화:
VG 풀: [used][used][used]...[free][free][free]...
↓ 10GB분 할당
[used][used][used]...[used][used][used]...
↑
home_lv에 추가됨
# 3. 파일시스템도 확장 (건물 증축)
resize2fs /dev/my_vg/home_lv
### 왜 두 번 해야 하나?
LV 확장 = 수영장 구역을 넓힌 것
파일시스템 확장 = 파일시스템 확장 = 넓어진 구역에 시설도 추가 설치하는 것
땅만 늘리고 건물을 안 늘리면?
→ 구역만 넓히고 시설을 안 늘리면, 빈 공간이 생겨도 못 쓴다
그래서 둘 다 해줘야 한다.
### 서비스 중단 없이 가능!
마운트 상태에서도 확장 가능 (ext4 기준)
→ /home 쓰는 중에도 늘릴 수 있다.
VG에 여유 공간이 없는 경우
- 새 디스크를 추가해야 한다.
# 1. 새 디스크에 파티션 생성
fdisk /dev/sdc # ← 새 디스크
# → /dev/sdc1 생성 (타입: 0x8E)
# 2. PV 생성
pvcreate /dev/sdc1 # ← sdc1
# 3. 기존 VG에 추가
vgextend my_vg /dev/sdc1 # ← sdc1
VG 변화:
Before: [sda1 PE들] → Free: 0
After: [sda1 PE들][sdb1 PE들] → Free: 10GB (새로 추가됨)
# 4. 이제 LV 확장 가능
lvextend -L +10G /dev/my_vg/home_lv
# 5. 파일시스템 확장
resize2fs /dev/my_vg/home_lv
사실 이럴 필요없이 lvextend -r -L +10G /dev/my_vg/home_lv
- r 옵션을 붙이면 LV를 늘림과 동시에 파일 시스템까지 자동으로 확장해준다.
etc.2 축소 시나리오
/home을 20GB → 10GB로 줄이고 싶을 때는?
축소는 확장보다 훨씬 위험하니 주의해서 해야 한다.
- 순서가 반대
- 확장: LV 먼저 → 파일시스템
- 축소: 파일시스템 먼저 → LV
- 마운트 해제 필요
- 확장은 마운트 상태에서 가능
- 축소는 언마운트해야 한다.
- 데이터 손실 위험
- 줄이려는 공간에 데이터가 있으면 날아간다.
축소 과정
# 1. 마운트 해제 (퇴거)
umount /home
왜? 파일시스템을 수정해야 하는데,
사용 중이면 데이터가 꼬일 수 있다.
# 2. 파일시스템 검사 (필수!)
e2fsck -f /dev/my_vg/home_lv
축소 전에 파일시스템이 정상인지 확인해야 한다.
문제 있는 상태에서 축소하면 데이터 손실이 발생한다.
# 3. 파일시스템 먼저 축소 (건물 먼저 줄이기)
resize2fs /dev/my_vg/home_lv 10G
파일시스템을 먼저 줄여서 뒤쪽을 비워놔야
LV를 안전하게 줄일 수 있다.
# 4. LV 축소 (땅 줄이기)
lvreduce -L 10G /dev/my_vg/home_lv
# 5. 다시 마운트 (재입주)
mount /dev/my_vg/home_lv /home
순서를 바꾸면 왜 위험한가?
- 잘못된 순서 (LV 먼저 축소)
- 파일시스템 뒷부분에 있던 데이터 손실이 발생한다.
'Infra > Linux' 카테고리의 다른 글
| sudo는 무적일까? (0) | 2026.01.11 |
|---|---|
| 어떻게 /etc/passwd와 같은 파일을 r,w 할까? (0) | 2026.01.09 |
| Linux inode (0) | 2026.01.05 |