리눅스 파일 시스템 완전 비교 가이드 — ext4 vs XFS vs Btrfs vs ZFS
리눅스 파일 시스템 완전 비교 가이드 — ext4 vs XFS vs Btrfs vs ZFS
"어떤 파일 시스템으로 포맷해야 하지?" 이 질문에 대한 답은 사용 목적에 따라 완전히 달라집니다. ext4는 안정성의 왕, XFS는 대용량 처리의 달인, Btrfs는 스냅샷 마법사, ZFS는 엔터프라이즈 끝판왕입니다.
1. 파일 시스템이란 무엇인가
파일 시스템은 디스크 위에 데이터를 저장하고 관리하는 규칙입니다. 마치 도서관의 도서 분류 체계와 같습니다. 같은 하드디스크라도 파일 시스템에 따라 읽기/쓰기 속도, 안정성, 기능이 완전히 달라집니다.
2. 4대 파일 시스템 핵심 비교
| 특징 | ext4 | XFS | Btrfs | ZFS |
|---|---|---|---|---|
| 최대 볼륨 크기 | 1 EB | 8 EB | 16 EB | 256 ZiB |
| 스냅샷 | 미지원 (LVM 필요) | 미지원 (LVM 필요) | 내장 (매우 빠름) | 내장 (강력함) |
| 축소(Shrink) | 가능 | 불가능 | 가능 | 불가능 |
| 압축 | 미지원 | 미지원 | 내장 (zstd/lzo) | 내장 (lz4/zstd) |
| RAID 내장 | mdadm 필요 | mdadm 필요 | Btrfs RAID 내장 | RAID-Z 내장 |
| 메모리 소모 | 매우 적음 | 적음 | 보통 | 많음 (RAM 필요) |
| 데이터 무결성 | 기본 | 기본 | 기본 (CoW) | checksum 대체 불가 |
| 커널 기본 내장 | 예 | 예 | 예 | 아니오 (라이선스) |
| 커널 도입 연도 | 1992 (ext) → 2008 (ext4) | 1993 | 2009 | 2005 (Solaris) → 2013 (Linux) |
3. ext4 — 리눅스의 오랜 표준
핵심 특징
ext4는 20년 이상 검증된 파일 시스템입니다. 버그가 거의 없고, 어떤 리눅스 배포판에서든 기본값으로 제공됩니다.
- journaling: 데이터 쓰기 전에 저널에 기록하여 시스템 비정상 종료 시 복구 속도가 빠름
- extent 기반 할당: 연속된 블록을 하나의 extent로 묶어 작은 파일 처리 속도 향상
- 延迟 할당 (Delayed Allocation): 쓰기 버퍼를 모았다가 한꺼번에 할당하여 파일 단편화 감소
practical 명령어
# ext4 포맷
sudo mkfs.ext4 /dev/sdb1
# 마운트 (기본 옵션)
sudo mount /dev/sdb1 /mnt/data
# 마운트 옵션 튜닝 — 읽기 중심 서버
sudo mount -o noatime,nodiratime,data=writeback /dev/sdb1 /mnt/data
# fstab에 영구 등록
echo '/dev/sdb1 /mnt/data ext4 defaults,noatime,nodiratime 0 2' | sudo tee -a /etc/fstab
# 디스크 사용량 확인
df -hT /mnt/data
# 조각 모음 (ext4는 자동 조각 모음이 없으므로 수동 필요)
sudo e4defrag /mnt/data
# 무결성 검사 (온라인 가능)
sudo e2fsck -f /dev/sdb1
best practice
/etc/fstab에noatime옵션을 넣으면 불필요한 접근 시간 기록을 생략하여 I/O 성능 향상data=writeback모드는 쓰기 성능이 가장 빠르지만 비정상 종료 시 데이터 손실 위험 약간 증가data=ordered(기본값)는 안정성과 성능의 균형이 가장 좋음
4. XFS — 대용량 처리의 달인
핵심 특징
XFS는 IRIX에서 개발된 고성능 파일 시스템으로, MySQL/PostgreSQL 같은 대규모 데이터베이스와 대용량 미디어 파일 처리에 최적화되어 있습니다.
- 일_allocation 그룹 (AG): 디스크를 독립적인 구역으로 나누어 동시 쓰기 처리 성능 향상
- B+tree 기반 디렉토리: 수백만 개 파일이 있어도 디렉토리 검색 속도 유지
- realtime 스트리밍: 미디어 스트리밍 같은 실시간 I/O에 특화
- 확장은 가능하나 축소 불가: 볼륨을 키우는 것은 가능하지만, 줄이는 것은 불가능
practical 명령어
# XFS 포맷
sudo mkfs.xfs /dev/sdb1
# 마운트
sudo mount /dev/sdb1 /mnt/data
# 마운트 옵션 — DB 서버용
sudo mount -o noatime,nodiratime,logbufs=8,logbsize=256k /dev/sdb1 /mnt/data
# fstab 등록
echo '/dev/sdb1 /mnt/data xfs defaults,noatime 0 2' | sudo tee -a /etc/fstab
# 디스크 사용량 확인
df -hT /mnt/data
xfs_info /dev/sdb1
# 조각 모음
sudo xfs_fsr /mnt/data
# 복구 도구
sudo xfs_repair /dev/sdb1
# 온라인 복구 (마운트된 상태에서)
sudo xfs_repair -L /dev/sdb1
best practice
- RHEL/CentOS/Fedora 계열은 기본값이 XFS — 그대로 유지하는 것이 가장 안전
- PostgreSQL의
shared_buffers와 XFS의noatime을 조합하면 DB 성능이 극대화됨 - 대용량 로그 파일 저장 시
logbufs=8옵션으로 로그 버퍼를 늘리면 쓰기 성능 향상
5. Btrfs — 스냅샷과 데이터 보호의 마법사
핵심 특징
Btrfs는 Copy-on-Write(CoW) 기반으로 파일 시스템 레벨에서 스냅샷, 복구, RAID, 실시간 압축을 지원합니다. 시놀로지 NAS 등에서 주로 채용하고 있습니다.
- Copy-on-Write (CoW): 데이터를 수정할 때 기존 블록을 건드리지 않고 새 블록에 기록 → 스냅샷이 순간적으로 생성됨
- 실시간 압축: 파일을 저장할 때 자동으로 압축 (zstd, lzo, zlib) → 디스크 용량 절약
- Btrfs RAID: mdadm 없이 파일 시스템 레벨에서 RAID 0/1/5/6/10 지원
- 서브볼륨: 하나의 파티션 안에서 독립적인 볼륨처럼 관리 가능
practical 명령어
# Btrfs 포맷 (single, RAID 없이)
sudo mkfs.btrfs /dev/sdb1
# Btrfs 포맷 (RAID 1 — 미러링)
sudo mkfs.btrfs -d raid1 -m raid1 /dev/sdb1 /dev/sdc1
# 마운트
sudo mount /dev/sdb1 /mnt/data
# fstab 등록
echo '/dev/sdb1 /mnt/data btrfs defaults,noatime 0 2' | sudo tee -a /etc/fstab
# 서브볼륨 생성
sudo btrfs subvolume create /mnt/data/@home
sudo btrfs subvolume create /mnt/data/@snapshots
# 스냅샷 생성 (1초 만에 완료)
sudo btrfs subvolume snapshot /mnt/data/@home /mnt/data/@snapshots/home-$(date +%Y%m%d)
# 스냅샷 목록 확인
sudo btrfs subvolume list /mnt/data
# 스냅샷 삭제
sudo btrfs subvolume delete /mnt/data/@snapshots/home-20260923
# 실시간 압축 확인
sudo btrfs filesystem defragment -r -czstd /mnt/data
# 디스크 사용량 확인 (서브볼륨별)
sudo btrfs filesystem usage /mnt/data
# 무결성 검사
sudo btrfs scrub start /mnt/data
sudo btrfs scrub status /mnt/data
best practice
- 스냅샷은 백업이 아닙니다. 하드디스크가 물리적으로 망가지면 스냅샷도 날아감 → 반드시 외부 백업과 병행
noatime옵션은 CoW와 결합하면 I/O 성능이 크게 향상됨- zstd 압축은 CPU 사용량이 약간 증가하지만 디스크 용량 30~50% 절약 효과가 있음
6. ZFS — 엔터프라이즈 끝판왕
핵심 특징
ZFS는 데이터 무결성, 강력한 RAID, 대용량 캐싱을 내장한 파일 시스템입니다. 여러 개의 하드디스크를 묶어 안전하고 거대한 저장소를 만들 때 최적입니다.
- checksum 기반 무결성: 모든 블록의 checksum을 계산하여 데이터 오염을 자동 탐지
- Self-healing: 미러/RAID-Z 구성 시 오염된 블록을 자동으로 정상 블록으로 복구
- ARC (Adaptive Replacement Cache): RAM을 디스크 캐시로 활용하여 반복 읽기 성능 극대화
- ZFS on Linux: 라이선스 문제로 커널 미내장, 별도 설치 필요
practical 명령어
# ZFS 설치 (Ubuntu/Debian)
sudo apt install zfsutils-linux
# ZFS 풀 생성 (단일 디스크)
sudo zpool create datapool /dev/sdb1
# ZFS 풀 생성 (RAID-Z1 — 1디스크 패러티)
sudo zpool create datapool raidz1 /dev/sdb1 /dev/sdc1 /dev/sdd1
# ZFS 풀 생성 (RAID-Z2 — 2디스크 패러티)
sudo zpool create datapool raidz2 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
# ZFS 풀 상태 확인
zpool status datapool
# ZFS 풀 사용량 확인
zpool list datapool
zfs list
# 스냅샷 생성
sudo zfs snapshot datapool/home@backup-20260923
# 스냅샷 목록 확인
sudo zfs list -t snapshot
# 스냅샷에서 복구
sudo zfs rollback datapool/home@backup-20260923
# 자동 스냅샷 (zfs-auto-snapshot)
sudo apt install zfs-auto-snapshot
# 매시간 자동 스냅샷 (최대 24개 유지)
sudo zfs set com.sun:auto-snapshot:hourly=true datapool/home
# ZFS 풀 온라인 복구
sudo zpool scrub datapool
# 디스크 추가 (온라인 확장)
sudo zpool add datapool /dev/sdf1
best practice
- ZFS는 RAM을 많이 소비합니다. 최소 8GB, 가능하면 16GB 이상 권장
arcstat명령어로 ARC 캐시 히트율을 모니터링하면 디스크 I/O 병목을 파악할 수 있음- RAID-Z1은 3디스크 이상에서만 의미 있음. 2디스크는 미러링이 더 안전
7. 성능 벤치마크 비교
동일한 NVMe SSD 환경에서의 일반적인 성능 비교입니다. 실제 성능은 하드웨어, 워크로드, 옵션에 따라 달라집니다.
| 작업 | ext4 | XFS | Btrfs (압축 OFF) | Btrfs (zstd) | ZFS (lz4) |
|---|---|---|---|---|---|
| 순수 읽기 (4K 랜덤) | 빠름 | 빠름 | 빠름 | 빠름 | 보통 (ARC 적중 시 매우 빠름) |
| 순수 쓰기 (4K 랜덤) | 빠름 | 매우 빠름 | 보통 | 느림 | 느림 |
| 대용량 스트리밍 쓰기 | 빠름 | 매우 빠름 | 빠름 | 빠름 | 빠름 |
| 스냅샷 생성 | — | — | 즉시 (0.1초 이내) | 즉시 | 즉시 |
| 파일 복사 | 보통 | 보통 | 매우 빠름 (CoW) | 매우 빠름 | 보통 |
| 디스크 용량 활용 | 보통 | 보통 | 좋음 (압축 시) | 매우 좋음 | 좋음 (lz4) |
핵심 포인트: Btrfs의 CoW는 파일 복사 시 물리적 복사 없이 포인터만 생성하므로 수 GB 파일도 순간적으로 복사됩니다. zstd 압축은 CPU 부하가 약간 있지만 디스크 용량 30~50%를 절약합니다.
8. 실무 선택 가이드
Case 1: "잘 모르겠고 안정적인 게 최고야" → ext4
일반적인 웹 서버, 가벼운 애플리케이션 서버, 개인용 리눅스 PC라면 ext4를 선택하세요. 수십 년간 검증된 안정성 덕분에 시스템이 예상치 못하게 다운되어도 데이터가 깨질 확률이 가장 적습니다.
# 가장 안전한 기본 구성
sudo mkfs.ext4 /dev/sdb1
sudo mount -o defaults,noatime,ordered /dev/sdb1 /mnt/data
Case 2: "대용량 DB나 미디어 파일을 다뤄요" → XFS
MySQL/PostgreSQL 등 대규모 DB 서버, 로그 데이터가 기가바이트 단위로 쌓이는 서버, 영상 파일 등을 다룬다면 XFS가 정답입니다.
# DB 서버 최적 구성
sudo mkfs.xfs /dev/sdb1
sudo mount -o noatime,logbufs=8,logbsize=256k /dev/sdb1 /var/lib/mysql
Case 3: "잦은 백업과 데이터 유실 방지가 중요해요" → Btrfs
가상 머신을 자주 생성하고 지우거나, 랜섬웨어 대비를 위해 매시간 파일 시스템을 백업해야 하는 환경이라면 Btrfs가 유용합니다.
# NAS/백업 최적 구성
sudo mkfs.btrfs /dev/sdb1
sudo mount -o defaults,noatime,compress=zstd /dev/sdb1 /mnt/data
sudo btrfs subvolume create /mnt/data/@data
sudo btrfs subvolume create /mnt/data/@snapshots
# 자동 스냅샷 스크립트 (crontab)
echo '0 * * * * root btrfs subvolume snapshot /mnt/data/@data /mnt/data/@snapshots/data-$(date +\%Y\%m\%d\%H)' > /etc/cron.d/btrfs-snapshot
Case 4: "수십 TB 전문 백업/스토리지 서버" → ZFS
여러 개의 하드디스크를 묶어 안전하고 거대한 저장소를 만들고 싶다면 ZFS를 추천합니다.
# 스토리지 서버 최적 구성
sudo zpool create -o ashift=12 datapool raidz2 /dev/sd{b,c,d,e}
sudo zfs create -o compress=lz4 -o atime=off datapool/data
sudo zfs create -o compress=zstd datapool/backup
sudo zfs set com.sun:auto-snapshot:daily=true datapool/data
9. 2026년 추천 공식
| 사용 목적 | 추천 파일 시스템 | 이유 |
|---|---|---|
| 일반 리눅스 PC/웹 서버 | ext4 | 검증된 안정성, 호환성 최고 |
| 대규모 DB/미디어 서버 | XFS | 대용량 I/O 처리 최적화 |
| 백업/가상화/NAS | Btrfs | CoW 스냅샷, 실시간 압축 |
| 전문 스토리지/엔터프라이즈 | ZFS | Self-healing, RAID-Z, 무결성 |
| Docker/컨테이너 호스트 | ext4 또는 XFS | Docker 공식 추천 |
최종 팁: 파일 시스템은 한번 포맷하면 바꾸기 어렵습니다. 도입 전 반드시 자신의 워크로드(I/O 패턴, 데이터 크기, 백업 요구사항)를 파악한 뒤 선택하세요.