[Linux] NVMe SSD 환경 파일 시스템 벤치마크: ext4, XFS, Btrfs, ZFS 성능 비교

목차

• 1. 왜 NVMe SSD에서는 파일 시스템 선택이 더 중요할까요?
• 2. ext4, XFS, Btrfs, ZFS를 쉽게 정리해보면
• 3. 벤치마크 전에 꼭 정해야 할 테스트 원칙
• 4. NVMe SSD 리눅스 파일 시스템 벤치마크 실전 준비
• 4-1. 테스트 장치 확인
• 4-2. 파일 시스템 생성 예시
• 4-3. 마운트 옵션 예시
• 4-4. fio 벤치마크 스크립트 예시
• 5. 파일 시스템별로 벤치마크 해석 포인트가 다릅니다
• 6. ⚠️ 제가 실제로 겪었던 트러블슈팅 포인트
• 6-1. 페이지 캐시 때문에 결과가 이상하게 잘 나올 때
• 6-2. Btrfs의 CoW가 로그/DB 파일에 불리할 때
• 6-3. ZFS는 메모리와 설정을 같이 봐야 합니다
• 6-4. discard/TRIM 처리 방식 차이
• 6-5. 압축 옵션은 공정하게 맞춰야 합니다
• 7. 검증과 결과 정리: 숫자보다 패턴을 보세요
• 8. 그래서 어떤 파일 시스템을 고르면 좋을까요?
• 9. 마무리: 성능 비교보다 더 중요한 것
• 정리 FAQ
• Q1. NVMe SSD에서는 무조건 XFS가 빠른가요?
• Q2. Btrfs나 ZFS는 느리기만 한가요?
• Q3. 벤치마크는 어떤 도구부터 시작하면 될까요?
• Q4. 결과가 매번 다르게 나오는데 정상인가요?

[Linux] NVMe SSD 환경 파일 시스템 벤치마크: ext4, XFS, Btrfs, ZFS 성능 비교

NVMe SSD 리눅스 파일 시스템 조합, 이거 생각보다 성능 차이가 꽤 크게 나더라고요. 저도 홈랩에서 VM 스토리지랑 컨테이너 볼륨을 굴리면서 처음엔 그냥 ext4로 통일했었는데, 실제로 써보니까 워크로드(작업 부하)에 따라 XFS가 더 편한 경우도 있고, Btrfs나 ZFS처럼 기능이 많은 파일 시스템이 운영 안정성 면에서 더 낫다고 느낀 순간도 있었습니다. 그래서 이번 글에서는 NVMe SSD 환경 리눅스 파일 시스템을 기준으로, ext4 성능, XFS 성능, Btrfs 성능, ZFS 성능을 어떻게 비교해야 하는지, 그리고 파일 시스템 벤치마크를 할 때 어떤 함정을 피해야 하는지 정리해보겠습니다.

중요한 포인트부터 말씀드리면, 벤치마크 숫자 하나만 보고 파일 시스템을 고르면 나중에 꼭 후회합니다. 순차 읽기/쓰기만 빠르다고 끝이 아니거든요. 메타데이터(파일 정보) 처리, 작은 파일 다량 생성, 스냅샷(시점 복사), 압축, 복구 편의성까지 같이 봐야 합니다. 여기서 제일 중요한 건 벤치마크는 숫자 놀이가 아니라 운영 시나리오 검증이어야 한다는 거예요.

NVMe SSD 위에서 여러 리눅스 파일 시스템이 서로 다른 특성과 워크로드를 가지는 모습을 한눈에 보여주는 개요 이미지입니다.

1. 왜 NVMe SSD에서는 파일 시스템 선택이 더 중요할까요?

예전 SATA SSD 시절에도 파일 시스템 차이는 있었지만, NVMe SSD로 오면 대기 시간(지연 시간)이 낮아지고 병렬 처리 성능이 올라가면서 병목이 더 위로 올라옵니다. 쉽게 말해, 디스크가 느려서 묻히던 차이가 파일 시스템 계층에서 더 잘 드러난다는 뜻입니다.

• ext4: 기본기가 탄탄하고 범용성이 좋습니다.
• XFS: 큰 파일, 병렬 I/O, 서버 워크로드에서 자주 거론됩니다.
• Btrfs: 스냅샷과 서브볼륨(하위 볼륨)이 강점입니다.
• ZFS: 데이터 무결성(데이터 정확성)과 고급 기능이 강력하지만 메모리 사용과 운영 복잡도도 같이 따라옵니다.

실제로 써보니까, VM 이미지처럼 큰 파일을 연속으로 다루는 환경과, CI 캐시나 컨테이너 레이어처럼 작은 파일이 쏟아지는 환경은 체감이 완전히 다르더라고요. 그래서 NVMe SSD 리눅스 파일 시스템 비교는 단순 평균이 아니라 시나리오별 해석이 핵심입니다.

2. ext4, XFS, Btrfs, ZFS를 쉽게 정리해보면

저도 처음엔 헷갈렸는데, 이렇게 보면 좀 편합니다.

파일 시스템	성격	강점	주의할 점
ext4	표준형	안정적, 관리 쉬움, 범용성 좋음	고급 스냅샷 기능은 별도 계층 필요
XFS	병렬 처리형	큰 파일, 높은 동시성, 서버 환경 적합	작은 파일/특정 메타데이터 패턴은 직접 검증 필요
Btrfs	기능 통합형	스냅샷, 압축, 서브볼륨	CoW(Copy-on-Write) 특성 이해 필요
ZFS	무결성 중심형	체크섬, 스냅샷, 압축, 관리 기능 풍부	메모리와 운영 방식 이해가 필요, 리눅스 기본 내장 FS는 아님

ext4 성능은 대체로 예측 가능하고 무난한 편입니다. 반면 XFS 성능은 병렬 쓰기나 대용량 파일 위주에서 장점이 보이는 경우가 많고요. Btrfs 성능은 기능을 많이 켜는 대신 워크로드에 따라 편차가 생길 수 있습니다. ZFS 성능도 압축, recordsize, ARC(메모리 캐시) 설정에 영향을 꽤 받습니다.

3. 벤치마크 전에 꼭 정해야 할 테스트 원칙

여기서 삽질을 가장 많이 합니다 ㅎㅎ 저도 예전에 캐시를 비우는 절차 없이 돌렸다가 결과가 너무 예쁘게 나와서 좋아했는데, 다시 보니까 거의 메모리 테스트였던 적이 있거든요.

1. 같은 NVMe SSD, 같은 파티션 크기, 같은 커널(운영체제 핵심) 환경에서 비교합니다.
2. 가능하면 파일 시스템마다 새로 생성한 빈 볼륨에서 시작합니다.
3. 순차 읽기/쓰기와 랜덤 읽기/쓰기, 둘 다 측정합니다.
4. 작은 파일 메타데이터 성능과 큰 파일 처리 성능을 분리해서 봅니다.
5. 압축, CoW, atime 같은 옵션은 켠 상태와 끈 상태를 구분합니다.
6. 최소 2~3회 반복 실행해서 편차를 확인합니다.

벤치마크 도구는 보통 fio를 많이 씁니다. 이유는 간단합니다. 블록 크기, 큐 깊이, 동시 작업 수를 세밀하게 조절할 수 있어서 실제 서버 부하에 가깝게 흉내 내기 좋거든요.

4. NVMe SSD 리눅스 파일 시스템 벤치마크 실전 준비

아래 예시는 테스트 디바이스를 별도 디스크 또는 실험용 파티션으로 가정합니다. 운영 중인 루트 파일 시스템에 바로 적용하면 위험합니다. 반드시 테스트 환경에서 진행하세요.

4-1. 테스트 장치 확인

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT,MODEL
nvme list

먼저 대상 NVMe 장치를 정확히 확인합니다. 장치명을 잘못 잡으면 진짜 눈물 납니다. 저도 예전에 테스트한다고 했다가 다른 디스크를 지울 뻔했었네요.

4-2. 파일 시스템 생성 예시

# ext4
sudo mkfs.ext4 /dev/nvme1n1p1

# XFS
sudo mkfs.xfs -f /dev/nvme1n1p1

# Btrfs
sudo mkfs.btrfs -f /dev/nvme1n1p1

# ZFS는 별도 풀(pool) 생성 방식 사용
sudo zpool create benchpool /dev/nvme1n1p1
sudo zfs create benchpool/testfs

ZFS는 ext4, XFS, Btrfs처럼 단순 mkfs 흐름과는 좀 다릅니다. 처음엔 이게 뭔가 싶었는데, ZFS는 파일 시스템만 따로 보는 게 아니라 스토리지 관리 계층까지 같이 보는 구조라서 그렇습니다.

4-3. 마운트 옵션 예시

# ext4
sudo mount -o noatime /dev/nvme1n1p1 /mnt/bench

# XFS
sudo mount -o noatime /dev/nvme1n1p1 /mnt/bench

# Btrfs
sudo mount -o noatime,compress=zstd /dev/nvme1n1p1 /mnt/bench

# ZFS
sudo zfs set atime=off benchpool/testfs
sudo zfs set compression=lz4 benchpool/testfs

noatime은 접근 시간(access time) 갱신을 줄여서 불필요한 쓰기를 줄이는 데 도움이 됩니다. 다만 환경에 따라 기본값이나 운영 정책이 다를 수 있으니 무조건 정답은 아닙니다.

벤치마크 대상 NVMe SSD, 마운트 포인트, fio 테스트 흐름을 단계별로 보여주는 실전 구성 이미지입니다.

4-4. fio 벤치마크 스크립트 예시

cat > fio-randread.fio <<'EOF'
[global]
ioengine=libaio
direct=1
runtime=60
time_based=1
group_reporting=1
filename=/mnt/bench/testfile.bin
size=8G

[randread-4k]
bs=4k
rw=randread
iodepth=32
numjobs=4
EOF

fio fio-randread.fio

cat > fio-seqwrite.fio <<'EOF'
[global]
ioengine=libaio
direct=1
runtime=60
time_based=1
group_reporting=1
filename=/mnt/bench/testfile.bin
size=8G

[seqwrite-1m]
bs=1m
rw=write
iodepth=32
numjobs=1
EOF

fio fio-seqwrite.fio

여기서 4K 랜덤 읽기는 작은 I/O가 많은 데이터베이스나 VM 메타데이터 패턴을 보는 데 좋고, 1M 순차 쓰기는 큰 파일 복사나 백업 이미지 생성 같은 상황을 가정하기 좋습니다.

5. 파일 시스템별로 벤치마크 해석 포인트가 다릅니다

같은 fio 결과라도 읽는 법이 다릅니다. 숫자만 보지 말고 특성까지 같이 봐야 합니다.

• ext4: 전반적으로 균형이 좋고, 기본 설정에서도 큰 이슈 없이 결과가 나오는 편입니다.
• XFS: 동시성(동시에 여러 작업 처리)과 대용량 파일 흐름에서 강점을 기대할 수 있습니다.
• Btrfs: 압축과 스냅샷은 장점이지만, CoW 특성 때문에 일부 쓰기 패턴은 결과를 따로 봐야 합니다.
• ZFS: recordsize, compression, ARC 같은 설정이 결과에 영향을 주므로 기본값만 보고 단정하면 안 됩니다.

실제로 써보니까 Btrfs와 ZFS는 기능이 성능 결과에 직접 개입합니다. 그래서 기능을 끈 상태, 켠 상태를 분리해서 비교하는 게 맞더라고요. 예를 들어 압축이 켜졌다고 무조건 느려지는 게 아니라, CPU 여유가 있고 데이터 압축률이 괜찮으면 오히려 체감 I/O가 줄어드는 경우도 있습니다.

6. ⚠️ 제가 실제로 겪었던 트러블슈팅 포인트

이 섹션은 진짜 중요합니다. 벤치마크는 잘못하면 재현성(다시 해도 비슷한 결과가 나오는 성질)이 박살 나거든요.

6-1. 페이지 캐시 때문에 결과가 이상하게 잘 나올 때

첫 실행보다 두 번째 실행이 비정상적으로 빠르면 페이지 캐시를 의심해야 합니다. direct I/O를 써도 워크로드에 따라 캐시 영향이 완전히 사라지지 않는 경우가 있어서, 테스트 순서와 파일 초기화 상태를 일정하게 맞추는 게 중요합니다.

6-2. Btrfs의 CoW가 로그/DB 파일에 불리할 때

작은 랜덤 업데이트가 많은 파일은 CoW 특성 때문에 쓰기 증폭(실제 기록량 증가)이 체감될 수 있습니다. 이런 경우는 파일 단위 NOCOW 설정 같은 운영 전략을 별도로 검토합니다. 다만 이건 워크로드 의존성이 커서, 무조건 끄는 식으로 접근하면 또 다른 장점을 놓칠 수 있습니다.

6-3. ZFS는 메모리와 설정을 같이 봐야 합니다

ZFS는 데이터 무결성과 관리 기능이 강력한 대신, 메모리 캐시 활용이 중요한 편입니다. ARC가 잘 동작하는 환경과 그렇지 않은 환경의 체감 차이가 꽤 있습니다. 저도 처음엔 "왜 이렇게 다르지?" 했었는데, 결국 테스트 장비 메모리 구성과 dataset 속성 차이였더라고요.

6-4. discard/TRIM 처리 방식 차이

온라인 discard를 바로 걸지, 주기적으로 fstrim을 돌릴지는 배포판과 운영 정책에 따라 다를 수 있습니다. 벤치마크 중에는 이 배경 작업이 개입하지 않게 관리하는 게 좋습니다.

6-5. 압축 옵션은 공정하게 맞춰야 합니다

Btrfs나 ZFS에서 압축을 켠 상태와 ext4/XFS 기본 상태를 그대로 비교하면, 그건 "파일 시스템 비교"이면서 동시에 "기능 켠 상태 비교"가 됩니다. 글의 목적에 따라 비교 기준을 명확히 나눠야 합니다.

CoW, 압축, 캐시, TRIM 같은 요소가 벤치마크 결과를 흔드는 원인을 설명하는 트러블슈팅 이미지입니다.

7. 검증과 결과 정리: 숫자보다 패턴을 보세요

이번 글에서는 의도적으로 특정 수치를 단정해서 넣지 않았습니다. NVMe SSD 모델, 커널, 마운트 옵션, 메모리 용량, 테스트 데이터 특성에 따라 결과가 꽤 달라지기 때문입니다. 대신 일반적으로 많이 보는 해석 패턴을 정리해보면 아래와 같습니다.

비교 항목	자주 관찰되는 경향	체크할 포인트
순차 읽기/쓰기	ext4, XFS가 단순 구성에서 무난한 결과를 내기 쉬움	대용량 파일 위주인지 확인
랜덤 4K	옵션과 큐 깊이에 따라 차이가 크게 남	DB/VM 패턴과 유사한지 확인
메타데이터 작업	파일 생성/삭제/rename 패턴에서 차이가 드러남	작은 파일 수가 많은지 확인
스냅샷/압축	Btrfs, ZFS가 기능상 이점이 큼	성능과 운영 편의성 함께 평가
운영 단순성	ext4가 가장 익숙하고 단순한 편	장애 대응 경험도 고려

검증 명령은 이런 식으로 같이 보시면 됩니다.

fio fio-randread.fio
fio fio-seqwrite.fio
iostst -x 1
vmstat 1
mount | grep /mnt/bench

iostat로 장치 사용률과 대기 시간을 보고, vmstat로 메모리와 시스템 상태를 같이 봅니다. 벤치마크 결과 파일만 보는 것보다 훨씬 해석이 쉬워집니다. 드디어 됐다! 싶은 순간이 여기서 오는데, 사실 이때부터가 진짜 시작입니다. 왜 빨랐는지, 왜 느렸는지를 설명할 수 있어야 하거든요.

8. 그래서 어떤 파일 시스템을 고르면 좋을까요?

정답은 하나가 아닙니다. 제가 직접 해보니 용도별로 이렇게 접근하는 게 현실적이었습니다.

1. 범용 서버, 운영 단순성 우선: ext4
2. 대용량 파일, 병렬 I/O, 로그성 서버: XFS 검토
3. 스냅샷, 서브볼륨, 유연한 관리: Btrfs 검토
4. 무결성, 스냅샷, 압축, 스토리지 통합 관리: ZFS 검토

혹시 이런 경험 있으신가요? 벤치마크만 보면 A가 빨랐는데, 운영해보니 B가 훨씬 편했던 경우요. 이게 진짜 자주 일어납니다. 그래서 파일 시스템 벤치마크는 최종 결론이 아니라 의사결정 재료로 보는 게 맞습니다.

체크리스트도 남겨보겠습니다.

• 내 워크로드는 작은 파일 위주인가, 큰 파일 위주인가
• 스냅샷이 꼭 필요한가
• 압축으로 얻을 이점이 있는가
• 복구와 운영 난이도를 감당할 수 있는가
• 팀이 익숙한 파일 시스템인가

워크로드별로 ext4, XFS, Btrfs, ZFS 중 어떤 선택이 어울리는지 요약한 비교 인포그래픽입니다.

9. 마무리: 성능 비교보다 더 중요한 것

NVMe SSD 리눅스 파일 시스템을 비교할 때 가장 중요한 건, "누가 더 빠르냐"보다 "내 환경에서 어떤 특성이 더 맞느냐"입니다. ext4 성능, XFS 성능, Btrfs 성능, ZFS 성능은 모두 의미가 있지만, 그 숫자는 설정과 부하에 따라 달라집니다. 반면 운영 편의성, 복구 경험, 스냅샷 전략, 백업 체계는 생각보다 오래 갑니다.

저는 요즘도 홈랩에서 새 워크로드를 올릴 때 먼저 fio로 최소한의 패턴 검증부터 합니다. 한 번 해두면 감이 생기고, 다음에는 훨씬 덜 헤매게 되더라고요. 다음 글에서는 fio 결과를 읽는 법, 그리고 VM/컨테이너/DB별로 어떤 테스트 프로파일을 써야 하는지를 따로 정리해볼 예정입니다. 이전 글에서 다룬 스토리지 모니터링 내용과 함께 보시면 더 이해가 쉬우실 겁니다.

정리 FAQ

Q1. NVMe SSD에서는 무조건 XFS가 빠른가요?

아닙니다. 워크로드에 따라 ext4가 더 무난하거나, 기능 요구 때문에 Btrfs나 ZFS가 더 적합할 수 있습니다.

Q2. Btrfs나 ZFS는 느리기만 한가요?

그렇게 단순하지 않습니다. 압축, 스냅샷, 무결성 같은 기능 가치까지 같이 봐야 합니다. 일부 상황에서는 운영 효율이 더 큰 장점이 됩니다.

Q3. 벤치마크는 어떤 도구부터 시작하면 될까요?

대부분의 경우 fio부터 시작하시면 됩니다. 순차/랜덤, 블록 크기, 큐 깊이를 조절해 실제 부하와 비슷하게 맞추기 좋습니다.

Q4. 결과가 매번 다르게 나오는데 정상인가요?

어느 정도는 정상입니다. 캐시, 백그라운드 작업, SSD 상태, 테스트 순서가 영향을 줄 수 있으니 조건을 최대한 통제해야 합니다.

📚 함께 읽으면 좋은 글

• 리눅스 환경변수 관리 실패 사례와 교훈: bashrc, profile, systemd 차이
• Arch Linux pacman 오류 해결: 키링, 업데이트 실패 실제 사례 분석
• Linux 6.9 LUKS suspend 보안 이슈: 디스크 암호화 키 노출과 대응 전략
• 리눅스 서버 보안 강화 체크리스트: SSH부터 시스템까지 10가지 필수 점검
• OpenStack Keystone 인증 시스템, 1년 운영 후기 및 보안 강화 팁