들어가기
리눅스 시스템을 운영하다 보면, 언젠가는 반드시 디스크를 다뤄야 하는 순간이 옵니다.
처음에는 용량이 충분해 보이던 시스템도 로그가 쌓이고, 데이터가 늘어나고, 서비스가 추가되면서 여유 공간이 줄어듭니다.
이번 글에서는 디스크를 추가하는 순간부터, 파티션을 나누고, 파일시스템을 만들고, 마운트하고, 스왑과 LVM까지 이어지는 흐름을 한 번에 정리해보려 합니다.
명령어 하나하나를 외우는 글이라기보다는,
디스크가 리눅스 안에서 어떤 단계로 관리되는지를 이해하는 데 초점을 맞췄습니다.
VM에 디스크 추가하기
실습 환경은 가상머신입니다.
이번 실습에서는 VMware에서 가상 디스크를 총 4개 추가한 상태를 기준으로 진행합니다.
운영체제 설치 시 기본 디스크 1개에 더해,
추가 실습을 위해 동일한 방식으로 1GB 디스크를 3개 더 추가했습니다.
결과적으로 리눅스 입장에서는 다음과 같은 디스크 구성이 됩니다.
/dev/sda: 기본 디스크 (OS 설치)/dev/sdb: 실습용 디스크/dev/sdc: LVM 확장 실습용 디스크/dev/sdd: 캐시 및 태깅 실습용 디스크
VMware 기준 디스크 추가 절차는 다음과 같습니다.
- Virtual Machine Settings
- Add… → Hard Disk
- SCSI → Create a new virtual disk
- 용량 1GB
- 이름은 기본값 유지
이 단계까지는 운영체제와는 아직 무관합니다.
단순히 가상 하드웨어를 여러 개 더 꽂은 상태입니다.
이제 리눅스가 이 디스크들을 어떻게 인식했는지 확인합니다.
리눅스에서 디스크 이름이 정해지는 방식
리눅스에서 디스크는 장치 파일로 표현됩니다.
인터페이스 종류에 따라 이름 규칙이 다릅니다.
- SCSI / SAS / SATA / USB →
/dev/sdX - IDE (구형) →
/dev/hdX - 가상 디스크(KVM, VirtIO) →
/dev/vdX
요즘 시스템에서는 대부분 /dev/sdX 형태를 사용합니다.
여기서 중요한 점은,
X에 해당하는 a, b, c… 순서는 물리적인 슬롯 순서가 아니라
커널이 디스크를 인식한 순서라는 점입니다.
따라서 재부팅이나 하드웨어 구성 변경에 따라 이름이 달라질 수 있습니다.
이것이 UUID를 사용하는 이유이기도 합니다.
블록 디바이스 확인하기
디스크를 추가한 뒤 가장 먼저 확인해야 할 명령은 lsblk입니다.
bashlsblk
이 단계에서 확인하는 것
lsblk는 현재 시스템에 연결된 블록 디바이스의 계층 구조를 보여줍니다.
처음 보는 독자라면, 여기서 최소한 아래 3가지만 확인하면 됩니다.
- 새 디스크가 잡혔는지 (
/dev/sdb,/dev/sdc,/dev/sdd가 보이는지) - 파티션이 있는지 (디스크 아래에
sdb1,sdb2같은 항목이 생겼는지) - 마운트가 되었는지 (MOUNTPOINTS 컬럼에 경로가 보이는지)
disk / part / lvm 의 의미
lsblk 출력에서 TYPE 컬럼은 대상의 성격을 말해줍니다.
disk: 실제 디스크 장치part: 디스크를 나눈 파티션lvm: LVM이 만든 논리 볼륨(실제로 마운트되는 대상)
디스크 작업에서는 이 구분이 계속 반복됩니다.
파일시스템과 UUID까지 같이 보고 싶다면
bashlsblk -f
-f 옵션을 붙이면 파일시스템 타입과 UUID를 함께 볼 수 있습니다.
/etc/fstab에 등록할 때 UUID가 필요하므로, 보통 이 옵션까지 같이 씁니다.
파티션 테이블과 파티셔닝 도구
디스크를 바로 사용할 수는 없습니다.
먼저 파티션 테이블을 만들고, 그 위에 파티션을 생성해야 합니다.
파티션 테이블이 필요한 이유
디스크는 그냥 큰 공간 하나입니다.
파티션 테이블은 이 공간을 어떻게 나눠 쓸지에 대한 지도에 가깝습니다.
- 어디부터 어디까지가 1번 파티션인지
- 어떤 파티션이 부팅에 쓰이는지
- 논리 파티션을 확장 영역 안에 어떻게 담는지
이 정보가 없으면 커널은 디스크를 “나눠진 형태”로 해석할 수 없습니다.
어떤 도구를 쓰면 되는지
여기서 자주 사용하는 도구는 세 가지입니다.
fdisk
- 가장 오래된 파티셔닝 도구
- 기본적으로 MBR(msdos) 파티션 테이블 사용
- 2TB 초과 디스크에는 한계
- 인터페이스가 단순하고 직관적
소형 디스크 실습에는 여전히 유용합니다.
gdisk
- GPT 파티션 테이블 전용
- 2TB 이상의 대용량 디스크 지원
- fdisk와 유사한 조작 방식
현대 서버 환경에서는 사실상 표준입니다.
parted
- MBR / GPT 모두 지원
- 비대화형(non-interactive) 사용 가능
- 자동화 스크립트에 적합
다만, 명령이 즉시 반영되기 때문에 실수 시 복구가 어렵습니다.
한 줄 정리
- 단순 실습 / 소형 디스크 →
fdisk - 대용량 디스크 / 서버 환경 →
gdisk - 자동화/스크립트 →
parted
BIOS와 UEFI, 그리고 파티션 테이블
시스템 펌웨어 방식에 따라 기본 파티션 테이블도 달라집니다.
- BIOS → MBR(msdos)
- UEFI → GPT
GPT는 파티션 정보를 디스크 전체에 분산 저장하며,
MBR보다 구조적으로 안정적입니다.
fdisk로 파티션 생성 흐름
이제 실제로 디스크 하나를 선택해 파티션을 생성해봅니다.
이번 실습에서는 아직 사용되지 않은 /dev/sdb 디스크를 대상으로 진행합니다.
bashfdisk /dev/sdb
실습에서 만들 파티션 구조
이번 글에서는 개념을 단순하게 보기 위해 /dev/sdb를 아래처럼 사용합니다.
/dev/sdb1: XFS 파일시스템으로 포맷 후/red에 마운트- (선택)
/dev/sdb2: swap이나 다른 실습용으로 남겨두기
실습에서 파티션을 여러 개로 나누는 이유는 “필요해서”라기보다,
파티션 번호와 구조가 어떻게 생기는지 체감하기 위해서입니다.
자주 쓰는 키
p: 현재 파티션 테이블 출력n: 새 파티션 생성d: 파티션 삭제w: 변경사항 저장 후 종료
MBR에서 꼭 알아야 하는 제한
MBR 방식에서는
- primary 최대 4개
- logical 파티션은 5번부터 시작
이라는 제약이 있습니다.
이 구조적 한계 때문에 GPT 파티션 테이블이 등장했습니다.
parted 사용 예시
parted는 자동화 친화적이라서,
실습에서도 “명령 한 줄로 구조를 만드는 느낌”을 보기 좋습니다.
아래 예시는 /dev/sdc 디스크를 GPT 방식으로 초기화하고,
400M + 나머지 공간으로 파티션을 나누는 흐름입니다.
bashparted /dev/sdc
mklabel gpt
mkpart primary 0% 400M
mkpart primary 400M 100%
print
주의할 점
parted는 fdisk처럼 “마지막에 저장(w)”하는 느낌이 약합니다.
명령이 곧바로 반영될 수 있어, 실수했을 때 되돌리기가 어렵습니다.
그래서 운영에서는 보통
- 작업 전
lsblk로 대상 디스크 확인 - 작업 후
print로 결과 확인
이 두 단계를 습관처럼 붙여서 진행합니다.
파티션 이후 선택지
파티션을 만들었다면, 이 블록 디바이스는 세 가지 용도로 사용할 수 있습니다.
- 파일시스템 생성 후 마운트
- swap 영역으로 사용
- raw 디바이스로 사용 (DB 등 특수 용도)
일반적인 서버 환경에서는 1번과 2번이 대부분입니다.
파일시스템 생성
파티션이 생성되면, 그 위에 파일시스템을 만들어야 실제로 사용할 수 있습니다.
이번 실습에서는 /dev/sdb1 파티션을 XFS 파일시스템으로 포맷합니다.
bashmkfs -t xfs /dev/sdb1
lsblk -f
파일시스템은 ‘포맷’입니다
mkfs는 “파일을 만드는 명령”이 아니라,
해당 블록 디바이스 위에 파일시스템 구조(메타데이터)를 새로 깔아버리는 작업입니다.
그래서 대상 디바이스를 잘못 지정하면 그대로 데이터가 날아갑니다.
실습에서는 괜찮지만 운영에서는 항상 한 번 더 확인하는 습관이 필요합니다.
왜 XFS를 많이 쓰는가
요즘 RHEL 계열의 기본 파일시스템은 XFS입니다.
- ext 계열보다 대용량에 유리
- 온라인 확장 지원
다만 모든 경우에 XFS가 정답인 것은 아닙니다.
디스크 검사/복구 방식이 ext 계열과 다르므로, 운영 기준에 맞춰 선택하는 편이 안전합니다.
UUID 확인
lsblk -f를 사용하면 파일시스템 타입과 UUID를 함께 확인할 수 있습니다.
나중에 /etc/fstab에 등록할 때 UUID가 필요합니다.
마운트와 언마운트
파일시스템을 만들었으면, 이제 경로에 붙여서 실제로 사용합니다.
bashmkdir /red
mount /dev/sdb1 /red
df -h
mount는 ‘연결’입니다
마운트는 디스크를 “복사”하는 게 아니라,
특정 경로에 파일시스템을 연결하는 작업입니다.
그래서 마운트되기 전에는 /red가 빈 폴더였지만,
마운트 이후에는 /dev/sdb1의 루트가 /red에 나타납니다.
언마운트
bashumount /red
umount는 장치를 떼어내는 작업입니다.
파일을 열어둔 상태라면 실패할 수 있으니,
필요하면 lsof나 fuser로 점유 프로세스를 확인하기도 합니다.
재부팅하면 왜 사라지는가
mount는 커널 메모리 위에 “현재 연결 상태”를 올리는 작업입니다.
재부팅하면 커널이 초기화되기 때문에, 마운트도 사라집니다.
그래서 영구적으로 사용하려면 /etc/fstab에 등록해야 합니다.
/etc/fstab 이해하기
fstab은 “부팅할 때 어떤 파일시스템을 어디에 붙일지”를 정의하는 파일입니다.
운영에서는 장치 이름(/dev/sdb1) 대신 UUID를 쓰는 편이 안전합니다.
bashcat /etc/fstab
각 필드 의미
- 장치 이름 또는 UUID
- 마운트 지점
- 파일시스템 타입
- 마운트 옵션
- dump 옵션 (현재는 거의 사용 안 함)
- fsck 검사 순서
XFS는 fsck를 사용하지 않기 때문에 보통 0으로 설정합니다.
예시
bashUUID=xxxx-xxxx /red xfs defaults 0 0
작성 후 검증
bashmount -a
mount -a는 fstab에 적힌 항목을 실제로 마운트해보는 테스트입니다.
오타가 있으면 여기서 바로 걸립니다.
Swap 영역
Swap은 메모리가 부족할 때를 대비한 안전장치입니다.
실습에서는 **파일시스템용 디스크(sdb)**와 분리해서,
OS 디스크(/dev/sda) 안에 swap 파티션이 있다고 가정하고 설명합니다.
실제 환경에서는 설치 과정에서 이미 swap이 잡혀 있는 경우가 많습니다.
lsblk -f로 swap 타입이 있는지 먼저 확인하는 편이 안전합니다.
swap 장치 확인
bashlsblk -f
swapon -s
이미 활성화된 swap이 있다면 swapon -s에 표시됩니다.
swap 만들기/활성화
bashmkswap /dev/sda2
swapon /dev/sda2
swapon -s
- 파일 스왑: 과거 방식, 권장하지 않음
- 디바이스 스왑: 현재 표준
priority 값으로 사용 우선순위를 조절할 수 있습니다.
fstab에 등록
bashUUID=yyyy-yyyy none swap defaults,pri=2 0 0
LVM의 등장 이유
디스크와 파티션만으로는 확장과 축소가 불편합니다.
예를 들어 /dev/sdb1에 파일시스템을 만들어 쓰다가 공간이 부족해졌다면,
전통적인 방식에서는
- 새 디스크를 붙이고
- 다시 파티션을 만들고
- 데이터를 옮기거나
- 서비스 중단을 고민해야 했습니다.
LVM은 이 문제를 해결하기 위해 등장했습니다.
LVM 계층 구조
- PV(Physical Volume) → 물리 디스크/파티션을 LVM이 쓸 수 있게 만든 단위
- VG(Volume Group) → 여러 PV를 묶어 만든 “저장소 풀”
- LV(Logical Volume) → 실제로 사용하는 논리 볼륨(파일시스템을 올리는 대상)
LVM 확장 흐름 실습
앞선 실습에서 /dev/sdc 디스크는 아직 사용되지 않은 상태입니다.
이 디스크를 LVM 확장용 디스크로 활용합니다.
전체 흐름
디스크 추가 → PV 생성 → VG 확장 → LV 확장 → 파일시스템 확장
이 순서를 반드시 지켜야 합니다.
1) PV 생성
bashpvcreate /dev/sdc
pvs
pvcreate는 디스크를 LVM이 관리할 수 있는 형태로 초기화합니다.
이 작업 이후부터 /dev/sdc는 “그냥 디스크”가 아니라 LVM의 PV로 취급됩니다.
2) VG 확장
bashvgextend vgcolor /dev/sdc
vgs
VG의 용량만 늘어난 상태입니다.
아직 LV나 파일시스템의 크기는 변하지 않습니다.
3) LV 확장
bashlvextend -L 960M /dev/vgcolor/lvred
lvextend -l 60 /dev/vgcolor/lvblue
lvs
여기까지는 블록 디바이스(LV) 크기만 늘어납니다.
4) 파일시스템 확장
bashdf -h
xfs_growfs /dev/vgcolor/lvred
resize2fs /dev/vgcolor/lvblue
df -h
- XFS는
xfs_growfs - ext4는
resize2fs
여기까지 해야 실제로 df -h에서 용량이 늘어난 것이 보입니다.
왜 두 번 늘려야 하는가
LVM은 “디스크/볼륨” 크기를 다루고,
파일시스템은 “그 위에 올라간 구조”를 다룹니다.
그래서 lvextend로 LV를 늘렸다고 해서
파일시스템이 자동으로 커지지 않습니다.
LVM 축소 시 주의점
축소는 확장보다 훨씬 조심해야 합니다.
순서를 잘못 잡으면 데이터가 잘립니다.
안전한 순서
- 파일시스템 축소
- (필요 시 검사)
- LV 축소
ext 계열에서는 보통 아래 흐름으로 진행합니다.
bashumount /blue
e2fsck -f /dev/vgcolor/lvblue
resize2fs /dev/vgcolor/lvblue 800M
lvreduce -L 800M /dev/vgcolor/lvblue
XFS는 온라인/오프라인을 막론하고 축소를 지원하지 않기 때문에,
XFS 파일시스템을 줄이는 실습은 일반적으로 “재구성(백업→재생성→복원)”으로 접근합니다.
그래서 운영에서는
- XFS는 확장 중심으로 설계
- 축소가 필요하면 ext 계열을 고려
처럼 처음 설계 단계에서 선택이 갈리는 경우도 있습니다.
LVM 캐시와 태깅
여기부터는 “필수 기능”이라기보다,
디스크가 많아지고 운영 기간이 길어질수록 체감이 커지는 기능들입니다.
LVM 캐시(Cache)
SSD를 캐시로 활용해 HDD 성능을 보완할 수 있습니다.
write-through
데이터가 HDD와 캐시에 동시에 기록됩니다.
안정성이 높지만 쓰기 성능 향상은 제한적입니다.
write-back
데이터가 먼저 캐시에 기록되고, 이후 HDD에 반영됩니다.
성능은 좋지만 장애 상황에서 데이터 유실 위험이 커집니다.
운영 환경에서 어떤 모드를 쓸지는 “성능”보다 “복구 전략”과 연결됩니다.
LVM 태깅(Tagging)
태깅은 PV/VG/LV에 라벨처럼 메타 정보를 붙이는 기능입니다.
- 용도별 분류(예: data, cache, backup)
- 운영/개발/테스트 구분
- 스크립트에서 특정 볼륨만 선택
디스크가 많아지면 구조를 문서 없이 파악하기 어렵습니다.
그럴 때 태깅이 관리 난이도를 낮춰줍니다.
정리
- 디스크는 한 번에 끝나는 작업이 아닙니다.
- 항상 **계층 구조(PV → VG → LV → FS)**를 의식해야 합니다.
- 명령어보다 흐름을 이해하는 것이 중요합니다.
가상머신을 통해 한번 실습을 하면 대략 감이 잡히실 겁니다.