LVM: 디스크 -> 마운트 과정

내가 도저히 부팅무터 마운트까지… 여러 세부 과정들이 이해가 되지 않아 매우 쉬운 비유와 함께 정리한 글이다.

• 해당 정리글에서는 MBR을 통한 파티셔닝만으로 설명을 합니다.
• 최근에는 GPT 방식 또한 많이 사용됩니다.

---

Ch.1 파티션 생성

"디스크를 큰 땅이라고 비유한다. 이 땅에 수영장을 만들 계획이다. 먼저 땅의 어느 부분을 사용할지 구역을 나눠야 한다.”

fdisk /dev/sdb

 

파티셔닝은 곧, 매우 큰 디스크라는 땅에 경계선을 긋는 작업이라고 볼 수 있다.

• 아직 아무것도 없는 빈 땅에 "여기서 여기까지는 1번 구역"이라고 표시하는 거다.
  • 아직 아무것도 없다니?
  • → 아직까지 물리 디스크만 존재하고 우리가 설정해준 것이 아무것도 없다.

그럼 실제 fdisk가 하는 일은 뭘까?

1. 디스크 맨 앞(섹터 0)의 MBR을 읽는다.
2. 사용자가 지정한 파티션 정보를 MBR 파티션 테이블에 기록한다.
   • 시작 위치: 2048 섹터
   • 크기: 10GB
   • 타입: 0x8E (Linux LVM)
3. MBR을 디스크에 저장

위와 같은 과정을 겪으면 큰 땅(디스크)은 아래와 같이 되어 있을 거다.

 

중요한 것은 파티션을 만들었다고 실제로 디스크에 벽이 생기는 것이 아니다.

• MBR이라는 안내판에 1번 구역은 여기서부터 여기까지다. 라고 적어놓는 것뿐이다.

---

Ch.2 PV 생성

"나눠놓은 땅에 물탱크를 설치한다. 이 물탱크가 나중에 수영장의 물 공급원이 된다.”

pvcreate /dev/sdb1

 

첫번째 일은 바로 파티션을 LVM이 관리할 수 있도록 등록하는 작업이다.

• "파티션에 '여기에 물탱크 설치됨'이라는 표시를 하고, 물탱크 내부를 일정한 크기(PE)로 나눠서 관리하기 쉽게 만든다.”
• 물탱크의 IN/OUT 통로가 좀 많겠지?

pvcreate는 뭘 하는데?

1. /dev/sdb1의 맨 앞에 LVM Label 기록
   • 이 파티션은 이제 LVM PV 입니다.
2. 메타데이터 영역 생성
   • PV의 고유 ID, 크기, PE 정보 등 저장
3. 나머지 공간을 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는 무슨 일을 하는데?

1. VG 메타데이터 생성
   • VG 이름: my_vg
   • VG 고유 ID
   • 소속된 PV 목록
   • 총 PE 개수, 사용 가능 PE 개수
2. 이 메타데이터를 각 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가 하는 일은 아래와 같다.

1. 필요한 PE 개수 계산 10GB ÷ 4MB = 2,560개 PE 필요
2. VG의 Free PE에서 2,560개 할당
3. LE ↔ PE 매핑 테이블 생성
4. /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 ← 다른 디스크
• 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가 하는 일은 아래와 같다.

1. /dev/my_vg/home_lv의 파일시스템 타입 확인 (ext4)
2. ext4 드라이버 로드
3. 슈퍼블록 읽어서 파일시스템 정보 파악
4. /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로 줄이고 싶을 때는?

 

축소는 확장보다 훨씬 위험하니 주의해서 해야 한다.

1. 순서가 반대
   • 확장: LV 먼저 → 파일시스템
   • 축소: 파일시스템 먼저 → LV
2. 마운트 해제 필요
   • 확장은 마운트 상태에서 가능
   • 축소는 언마운트해야 한다.
3. 데이터 손실 위험
   • 줄이려는 공간에 데이터가 있으면 날아간다.

축소 과정

# 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 먼저 축소)
  • 파일시스템 뒷부분에 있던 데이터 손실이 발생한다.