목차
TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크
TrueNAS 파일 시스템 성능 이야기는 생각보다 단순하지 않더라고요. 저도 처음엔 "같은 SSD에 올리면 파일 시스템만 바꿔서 보면 되는 거 아닌가?" 싶었는데, 실제로 파고들어 보니 정말 그렇지 않더라고요. 특히 TrueNAS Scale은 기본 저장소 계층이 사실상 ZFS(OpenZFS, 오픈지에프에스) 중심으로 설계돼 있어서, Btrfs(비트리 에프에스)나 ext4(익스트포)를 TrueNAS 풀(pool, 스토리지 집합) 대체재처럼 다루면 바로 비교가 틀어집니다. 그래서 이번 글은 "TrueNAS에서 ZFS를 써야 하나?"라는 질문에 답하기 위해, 동일한 리눅스 계열 환경에서 ZFS, Btrfs, ext4를 같은 방식으로 벤치마크하고 그 결과를 NAS 성능 관점에서 해석하는 방향으로 정리해보겠습니다.
제가 홈랩에서 이런 테스트를 할 때 가장 많이 보는 건 절대 수치 하나가 아니라 패턴입니다. 순차 읽기/쓰기, 작은 블록 랜덤 I/O, 스냅샷 이후 쓰기 지연, 체크섬(checksum, 데이터 무결성 검사용 해시) 오버헤드 같은 것들이요. 숫자 한 줄만 보면 쉬워 보이는데, 실제 운영에서는 그 숫자보다 "왜 이런 결과가 나왔는지"를 이해하는 쪽이 훨씬 중요하거든요.
TrueNAS 환경에서 ZFS를 기준으로 두고 Btrfs, ext4를 비교하는 전체 구조를 보여주는 개요 이미지입니다.
TrueNAS 파일 시스템 성능 비교에서 먼저 짚어야 할 전제
여기서 중요한 포인트가 하나 있습니다. TrueNAS의 저장소 풀은 ZFS 기반으로 다루는 것이 공식 문서 흐름과 기능 구조에 맞습니다. 스냅샷(snapshot, 시점 복제), 스크럽(scrub, 무결성 검사), 데이터셋(dataset, ZFS 하위 파일 시스템), 풀 업그레이드 같은 핵심 기능이 ZFS를 중심으로 설계돼 있거든요. 그래서 TrueNAS 파일 시스템 성능을 논할 때 Btrfs나 ext4를 TrueNAS 내부의 동등한 선택지처럼 비교하면 오해가 생기더라고요.
쉽게 말해 이렇게 보시면 됩니다.
- ZFS: TrueNAS의 본체에 가까운 기본 철학입니다.
- Btrfs: 리눅스에서 ZFS와 비교 대상으로 자주 거론되는 COW(Copy-On-Write, 쓰기 시 새 블록 생성) 파일 시스템입니다.
- ext4: 기능은 비교적 단순하지만 오버헤드가 낮아서 기준선(baseline)으로 보기 좋은 전통적인 저널링 파일 시스템입니다.
그래서 이 글의 비교는 "TrueNAS에서 셋 중 하나를 선택한다"가 아니라, ZFS 벤치마크 결과가 왜 다르게 보이는지 이해하기 위한 상대 비교라고 보시면 정확합니다.
ZFS, Btrfs, ext4를 쉽게 풀어보면
저도 처음엔 이게 뭔가 싶었는데, 파일 시스템은 결국 "데이터를 어떤 방식으로 쓰고, 보호하고, 복구하느냐"의 차이더라고요.
| 파일 시스템 | 핵심 구조 | 강점 | 성능 해석 포인트 |
|---|---|---|---|
| ZFS | COW, 체크섬, 풀/데이터셋 통합 | 무결성, 스냅샷, 복제, 관리성 | 안전장치가 많아서 쓰기 오버헤드가 생길 수 있음 |
| Btrfs | COW, 서브볼륨(subvolume, 하위 볼륨), 스냅샷 | 유연성, 리눅스 친화성 | 워크로드에 따라 COW 비용이 민감하게 드러남 |
| ext4 | 저널링(journaling, 메타데이터 기록) | 단순함, 폭넓은 호환성 | 기능 오버헤드가 적어 순수 I/O 기준선으로 좋음 |
ZFS는 파일 시스템과 볼륨 매니저(volume manager, 디스크 집합 관리)를 같이 들고 가는 느낌이더라고요. 그래서 스냅샷, 압축(compression, 데이터 압축), 스크럽 같은 기능이 아주 자연스럽게 붙습니다. 대신 메모리와 설계 이해도가 어느 정도 필요한 게 맞습니다.
Btrfs 성능은 꽤 흥미로운데요. 같은 COW 계열이라도 구현 방식과 운영 습관에 따라 체감이 달라집니다. 스냅샷을 많이 쓰는 환경, 작은 파일이 자주 바뀌는 환경에서는 생각보다 결과가 요동치기도 하더라고요.
ext4 NAS 구성을 따로 운영해보면, 기능보다 단순성과 예측 가능성이 장점으로 드러나더라고요. 다만 TrueNAS처럼 스토리지 무결성과 스냅샷 자동화까지 한 번에 챙기려는 목적이라면 결국 ZFS 쪽으로 다시 돌아오게 되는 경우가 많습니다.
벤치마크 설계: 숫자보다 조건 통제가 먼저입니다
벤치마크는 명령어보다 조건 통제가 더 중요합니다. 제가 직접 해보니 여기서 한 번 삐끗하면 결과가 완전히 엉뚱하게 나와요. 특히 ARC(Adaptive Replacement Cache, ZFS 메모리 캐시), 리눅스 페이지 캐시(page cache, 운영체제 파일 캐시), SSD SLC 캐시 같은 요소가 섞이면 파일 시스템 차이가 아니라 캐시 차이만 보게 되거든요.
- 동일한 하드웨어를 사용합니다. CPU, RAM, SSD/HDD, 컨트롤러를 고정합니다.
- 각 파일 시스템은 빈 디스크에서 새로 생성합니다.
- 같은 마운트 포인트 구조와 같은 테스트 파일 크기를 사용합니다.
- 벤치마크 전에 캐시 영향을 최소화합니다.
- 순차 읽기/쓰기와 랜덤 읽기/쓰기를 분리해서 봅니다.
- 스냅샷 이후 쓰기 성능도 따로 확인합니다.
테스트 워크로드는 보통 아래 네 가지면 충분합니다.
- 대용량 순차 읽기
- 대용량 순차 쓰기
- 4K 또는 16K 랜덤 읽기/쓰기
- 동시 접속 환경을 가정한 mixed read/write
혹시 이런 경험 있으신가요? 같은 장비인데 한 번은 ZFS가 느리고, 다른 날은 ext4가 이상하게 느립니다. 이런 경우 대부분 파일 시스템 문제가 아니라 캐시가 안 지워졌거나 테스트 순서가 꼬인 경우가 많더라고요. 저도 삽질 좀 했습니다 ㅎㅎ
실전 구현: ZFS, Btrfs, ext4 테스트 환경 만들기
여기서는 리눅스 셸 기준으로 예시를 잡겠습니다. TrueNAS 본체에서 ext4나 Btrfs를 운영용 풀로 올리는 흐름이 아니라, 동일한 리눅스 계열 테스트 노드에서 상대 비교를 수행하는 방식입니다.
1. 디스크 확인
lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINT
sudo wipefs -a /dev/sdb
sudo wipefs -a /dev/sdc
sudo wipefs -a /dev/sdd테스트용 디스크는 반드시 비워두세요. 기존 시그니처(signature, 디스크 식별 정보)가 남아 있으면 생성 단계에서 꼬일 수 있습니다.
2. ext4 생성
sudo mkfs.ext4 -F /dev/sdb
sudo mkdir -p /mnt/bench-ext4
sudo mount /dev/sdb /mnt/bench-ext43. Btrfs 생성
sudo mkfs.btrfs -f /dev/sdc
sudo mkdir -p /mnt/bench-btrfs
sudo mount /dev/sdc /mnt/bench-btrfs4. ZFS 풀 생성
sudo zpool create bench /dev/sdd
sudo zfs create bench/data
sudo zfs set compression=lz4 bench/dataZFS는 풀과 데이터셋을 나눠서 보는 습관이 중요합니다. TrueNAS Scale에서도 운영 관점은 거의 이 사고방식으로 이어집니다.
ZFS 풀과 데이터셋, ext4와 Btrfs 마운트 경로를 같은 조건으로 맞춘 테스트 구성 이미지입니다.
5. fio 작업 파일 준비
cat > fio-seq-write.fio <<'EOF'
[global]
ioengine=libaio
direct=1
runtime=60
time_based=1
group_reporting=1
size=8G
filename=testfile
[seqwrite]
bs=1M
rw=write
iodepth=32
EOF랜덤 I/O도 별도 job 파일로 분리하는 게 좋습니다.
cat > fio-randrw.fio <<'EOF'
[global]
ioengine=libaio
direct=1
runtime=60
time_based=1
group_reporting=1
size=4G
filename=testfile
[randrw]
bs=4k
rw=randrw
rwmixread=70
iodepth=32
EOF6. 각 파일 시스템에서 동일하게 실행
cd /mnt/bench-ext4 && fio ~/fio-seq-write.fio
cd /mnt/bench-btrfs && fio ~/fio-seq-write.fio
cd /bench/data && fio ~/fio-seq-write.fio경로는 배포판과 설정에 따라 달라질 수 있습니다. ZFS 데이터셋 마운트 경로는 zfs list로 먼저 확인하세요.
⚠️ 실제로 많이 겪는 문제와 트러블슈팅
이 섹션은 꼭 넣고 싶었습니다. 벤치마크는 명령어보다 삽질 포인트가 더 중요하거든요.
- 캐시 때문에 두 번째 결과가 더 잘 나오는 문제
첫 번째 테스트가 디스크 성능이 아니라 캐시 예열 역할을 해버릴 수 있어요. 테스트 순서를 바꾸면서 여러 번 반복해서 평균적인 경향만 보세요. - ZFS 압축 설정을 빼먹는 문제
TrueNAS에서 많이 쓰는compression=lz4를 끄고 측정하면 실제 운영과 괴리가 생기더라고요. 반대로 비교를 엄격히 하려면 세 파일 시스템 모두 압축 없는 기준과 운영 기준을 나눠 보시는 게 좋습니다. - Btrfs에서 스냅샷 후 쓰기 지연이 체감되는 문제
작은 파일이 자주 바뀌는 워크로드에서는 COW 영향이 꽤 보일 수 있어요. 로그성 데이터나 VM 이미지 파일은 별도로 성격을 나눠 측정해야 합니다. - ext4가 무조건 빠르다고 단정하는 문제
순수 쓰기만 보면 그럴 때가 있지만, 스냅샷/체크섬/복구 편의성까지 포함하면 운영 총비용(total cost of operation, 실제 운영 부담)은 완전히 다른 얘기입니다. - TrueNAS에서 ext4, Btrfs를 그대로 대체재처럼 보는 문제
이건 비교 관점 자체가 어긋난 경우예요. TrueNAS의 핵심 기능 체인은 ZFS를 전제로 보는 편이 맞습니다.
저는 예전에 ARC를 충분히 비우지 않은 상태에서 ZFS 벤치마크를 돌리고 "이상하게 읽기가 너무 잘 나오네?" 하고 한참 들여다본 적이 있습니다. 나중에 보니 디스크가 아니라 메모리 읽기였어요. 드디어 원인을 찾았을 때 허탈하더라고요.
검증과 결과 해석: 무엇을 보면 되는가
TrueNAS 파일 시스템 성능을 해석할 때는 절대값보다 아래 순서로 보시면 훨씬 정확해요.
- 순차 읽기/쓰기: 대용량 미디어, 백업 파일, 아카이브 용도에 가깝습니다.
- 랜덤 I/O: VM, DB, 메타데이터가 많은 워크로드와 더 가깝습니다.
- 스냅샷 이후 성능 변화: 운영 환경에서 체감이 크게 나는 부분입니다.
- 복구와 무결성: 장애 이후 사람을 살리는 기능인지 봐야 합니다.
제가 실제로 써보는 관점에서 정리하면 보통 이런 경향으로 읽혀요.
| 항목 | 대체로 유리한 쪽 | 해석 |
|---|---|---|
| 순차 쓰기 | ext4 또는 튜닝된 ZFS | 오버헤드가 적은 ext4가 기준선 역할을 잘함 |
| 무결성 검증 | ZFS | 체크섬과 스크럽 체계가 강점 |
| 스냅샷 관리 | ZFS, Btrfs | ext4는 기본 구조상 비교 우위가 적음 |
| 운영 일관성 | ZFS | TrueNAS와의 결합도가 높아 관리 흐름이 자연스러움 |
| 단순한 범용성 | ext4 | 호환성과 익숙함이 장점 |
ZFS 벤치마크를 볼 때 흔히 하는 오해가 하나 있어요. ext4보다 숫자가 조금 낮게 나오면 "ZFS가 느리다"라고 바로 결론 내리는 건데요. 사실 ZFS는 체크섬, 스냅샷, 풀 관리, 데이터 무결성 같은 운영 기능까지 포함한 저장소 플랫폼에 가깝습니다. 그래서 같은 MB/s라도 의미가 다르더라고요.
순차 I/O와 랜덤 I/O 결과를 한눈에 비교하고, TrueNAS 스타일의 스토리지 대시보드 느낌을 함께 담은 이미지입니다.
반대로 Btrfs 성능은 꽤 상황 의존적이더라고요. 스냅샷 활용과 유연한 운영이 장점이지만, NAS를 장기 보관 스토리지처럼 운영할 때는 ZFS의 관리 모델이 더 편하다고 느끼는 분이 많습니다. 저도 백업과 아카이브는 결국 ZFS 쪽으로 정착했었습니다.
TrueNAS Scale 기준으로 보면 무엇을 선택해야 하나
결론은 생각보다 명확해요. TrueNAS Scale을 메인 NAS로 운영한다면, 파일 시스템 선택 문제는 사실상 ZFS를 어떻게 잘 쓸 것인가의 문제에 가깝습니다. ext4와 Btrfs는 비교 대상으로는 유익하지만, TrueNAS 내부 운영 철학까지 합치면 ZFS가 중심입니다.
- 백업 무결성이 최우선이면 ZFS
- 스냅샷과 복제가 중요하면 ZFS
- 순수 리눅스 범용 서버에서 단순 볼륨이 필요하면 ext4도 여전히 강력
- 리눅스 네이티브 스냅샷 실험용이라면 Btrfs도 재미있음
여기서 중요한 포인트! TrueNAS 파일 시스템 성능은 결국 "가장 빠른 파일 시스템"이 아니라 "내 데이터와 운영 방식에 맞는 저장소 모델"을 찾는 과정입니다. 숫자만 따라가면 나중에 복구, 스냅샷, 확장성에서 후회하는 경우가 꽤 많더라고요.
ZFS, Btrfs, ext4의 장단점과 추천 사용 시나리오를 한 장으로 정리한 요약 이미지입니다.
정리와 다음 단계
이번 비교를 한 줄로 정리하면 이렇습니다. ext4는 기준선, Btrfs는 비교군, TrueNAS의 실전 선택은 ZFS입니다. 저도 처음엔 파일 시스템별 최고 속도만 보려고 했었는데, 실제로 써보니까 NAS는 속도보다 무결성, 스냅샷, 장애 대응이 훨씬 오래 남더라고요.
다음 단계로는 아래 세 가지를 권합니다.
- 같은 SSD 또는 HDD로 직접
fio를 돌려 보세요. - ZFS에서는 압축 on/off, 레코드 크기(recordsize, 블록 크기 정책), 동기 쓰기(sync) 조건을 나눠 보세요.
- 실사용 워크로드, 예를 들어 SMB 공유, 백업 저장소, VM 스토어를 따로 측정해 보세요.
이전 글에서 다룬 스토리지 튜닝 내용이 있다면 같이 보셔도 좋고, 다음 글에서는 TrueNAS Scale에서 ZFS 튜닝: recordsize, compression, ARC를 어떻게 잡아야 하는가를 이어서 다뤄볼 예정입니다. 이 부분이 진짜 체감 성능에 더 크게 영향을 주거든요. 혹시 지금 벤치마크를 준비 중이시라면, 먼저 테스트 조건 통제부터 챙겨보세요. 그게 반은 먹고 들어갑니다. 진짜로요.
'IT > HomeLabs' 카테고리의 다른 글
| [홈랩] 홈서버 마이그레이션, Intel NUC로 저전력 전환하기 (1) | 2026.06.23 |
|---|---|
| [HomeLabs] 홈랩 Matter 통합, 흔히 겪는 문제와 해결책: 디버깅 로그 분석 (1) | 2026.06.21 |
| [HomeLabs] Matter 프로토콜, 홈 자동화의 미래: 1년 사용 후기 및 실제 적용 사례 (0) | 2026.06.20 |
| [HomeLabs] 홈 어시스턴트 Matter 허브: 실제 사용기 및 통합 성공 사례 (1) | 2026.06.19 |
| [HomeLabs] 10G 네트워크 비용, 홈랩에 정말 필요할까? 비용 효율성 심층 분석 (0) | 2026.06.17 |
| [HomeLabs] 홈 어시스턴트 외부 서비스 연동 실패 분석: 커넥티드 카로 본 홈랩 보안과 프라이버시 (0) | 2026.06.15 |
