13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Btrfs 성능

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

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

    목차

    [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 리눅스 파일 시스템 벤치마크 구성도

    벤치마크 대상 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 기본 상태를 그대로 비교하면, 그건 “파일 시스템 비교”이면서 동시에 “기능 켠 상태 비교”가 됩니다. 글의 목적에 따라 비교 기준을 명확히 나눠야 합니다.

    Btrfs와 ZFS 옵션이 NVMe SSD 성능에 미치는 영향 이미지

    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가 훨씬 편했던 경우요. 이게 진짜 자주 일어납니다. 그래서 파일 시스템 벤치마크는 최종 결론이 아니라 의사결정 재료로 보는 게 맞습니다.

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

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

    워크로드별로 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 상태, 테스트 순서가 영향을 줄 수 있으니 조건을 최대한 통제해야 합니다.

  • [HomeLabs] TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크

    [HomeLabs] TrueNAS 파일 시스템 성능 비교: ZFS, Btrfs, ext4 실측 벤치마크

    목차

    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 환경에서 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 캐시 같은 요소가 섞이면 파일 시스템 차이가 아니라 캐시 차이만 보게 되거든요.

    1. 동일한 하드웨어를 사용합니다. CPU, RAM, SSD/HDD, 컨트롤러를 고정합니다.
    2. 각 파일 시스템은 빈 디스크에서 새로 생성합니다.
    3. 같은 마운트 포인트 구조와 같은 테스트 파일 크기를 사용합니다.
    4. 벤치마크 전에 캐시 영향을 최소화합니다.
    5. 순차 읽기/쓰기와 랜덤 읽기/쓰기를 분리해서 봅니다.
    6. 스냅샷 이후 쓰기 성능도 따로 확인합니다.

    테스트 워크로드는 보통 아래 네 가지면 충분합니다.

    • 대용량 순차 읽기
    • 대용량 순차 쓰기
    • 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-ext4

    3. Btrfs 생성

    sudo mkfs.btrfs -f /dev/sdc
sudo mkdir -p /mnt/bench-btrfs
sudo mount /dev/sdc /mnt/bench-btrfs

    4. ZFS 풀 생성

    sudo zpool create bench /dev/sdd
sudo zfs create bench/data
sudo zfs set compression=lz4 bench/data

    ZFS는 풀과 데이터셋을 나눠서 보는 습관이 중요합니다. TrueNAS Scale에서도 운영 관점은 거의 이 사고방식으로 이어집니다.

    TrueNAS 파일 시스템 성능 테스트를 위한 ZFS 풀과 ext4, Btrfs 구성 이미지

    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
EOF

    6. 각 파일 시스템에서 동일하게 실행

    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 파일 시스템 성능을 해석할 때는 절대값보다 아래 순서로 보시면 훨씬 정확해요.

    1. 순차 읽기/쓰기: 대용량 미디어, 백업 파일, 아카이브 용도에 가깝습니다.
    2. 랜덤 I/O: VM, DB, 메타데이터가 많은 워크로드와 더 가깝습니다.
    3. 스냅샷 이후 성능 변화: 운영 환경에서 체감이 크게 나는 부분입니다.
    4. 복구와 무결성: 장애 이후 사람을 살리는 기능인지 봐야 합니다.

    제가 실제로 써보는 관점에서 정리하면 보통 이런 경향으로 읽혀요.

    항목 대체로 유리한 쪽 해석
    순차 쓰기 ext4 또는 튜닝된 ZFS 오버헤드가 적은 ext4가 기준선 역할을 잘함
    무결성 검증 ZFS 체크섬과 스크럽 체계가 강점
    스냅샷 관리 ZFS, Btrfs ext4는 기본 구조상 비교 우위가 적음
    운영 일관성 ZFS TrueNAS와의 결합도가 높아 관리 흐름이 자연스러움
    단순한 범용성 ext4 호환성과 익숙함이 장점

    ZFS 벤치마크를 볼 때 흔히 하는 오해가 하나 있어요. ext4보다 숫자가 조금 낮게 나오면 “ZFS가 느리다”라고 바로 결론 내리는 건데요. 사실 ZFS는 체크섬, 스냅샷, 풀 관리, 데이터 무결성 같은 운영 기능까지 포함한 저장소 플랫폼에 가깝습니다. 그래서 같은 MB/s라도 의미가 다르더라고요.

    TrueNAS 파일 시스템 성능과 ZFS 벤치마크 결과를 보여주는 대시보드 이미지

    순차 I/O와 랜덤 I/O 결과를 한눈에 비교하고, TrueNAS 스타일의 스토리지 대시보드 느낌을 함께 담은 이미지입니다.

    반대로 Btrfs 성능은 꽤 상황 의존적이더라고요. 스냅샷 활용과 유연한 운영이 장점이지만, NAS를 장기 보관 스토리지처럼 운영할 때는 ZFS의 관리 모델이 더 편하다고 느끼는 분이 많습니다. 저도 백업과 아카이브는 결국 ZFS 쪽으로 정착했었습니다.

    TrueNAS Scale 기준으로 보면 무엇을 선택해야 하나

    결론은 생각보다 명확해요. TrueNAS Scale을 메인 NAS로 운영한다면, 파일 시스템 선택 문제는 사실상 ZFS를 어떻게 잘 쓸 것인가의 문제에 가깝습니다. ext4와 Btrfs는 비교 대상으로는 유익하지만, TrueNAS 내부 운영 철학까지 합치면 ZFS가 중심입니다.

    • 백업 무결성이 최우선이면 ZFS
    • 스냅샷과 복제가 중요하면 ZFS
    • 순수 리눅스 범용 서버에서 단순 볼륨이 필요하면 ext4도 여전히 강력
    • 리눅스 네이티브 스냅샷 실험용이라면 Btrfs도 재미있음

    여기서 중요한 포인트! TrueNAS 파일 시스템 성능은 결국 “가장 빠른 파일 시스템”이 아니라 “내 데이터와 운영 방식에 맞는 저장소 모델”을 찾는 과정입니다. 숫자만 따라가면 나중에 복구, 스냅샷, 확장성에서 후회하는 경우가 꽤 많더라고요.

    TrueNAS 파일 시스템 성능 관점에서 ZFS, Btrfs, ext4를 요약한 인포그래픽

    ZFS, Btrfs, ext4의 장단점과 추천 사용 시나리오를 한 장으로 정리한 요약 이미지입니다.

    정리와 다음 단계

    이번 비교를 한 줄로 정리하면 이렇습니다. ext4는 기준선, Btrfs는 비교군, TrueNAS의 실전 선택은 ZFS입니다. 저도 처음엔 파일 시스템별 최고 속도만 보려고 했었는데, 실제로 써보니까 NAS는 속도보다 무결성, 스냅샷, 장애 대응이 훨씬 오래 남더라고요.

    다음 단계로는 아래 세 가지를 권합니다.

    1. 같은 SSD 또는 HDD로 직접 fio를 돌려 보세요.
    2. ZFS에서는 압축 on/off, 레코드 크기(recordsize, 블록 크기 정책), 동기 쓰기(sync) 조건을 나눠 보세요.
    3. 실사용 워크로드, 예를 들어 SMB 공유, 백업 저장소, VM 스토어를 따로 측정해 보세요.

    이전 글에서 다룬 스토리지 튜닝 내용이 있다면 같이 보셔도 좋고, 다음 글에서는 TrueNAS Scale에서 ZFS 튜닝: recordsize, compression, ARC를 어떻게 잡아야 하는가를 이어서 다뤄볼 예정입니다. 이 부분이 진짜 체감 성능에 더 크게 영향을 주거든요. 혹시 지금 벤치마크를 준비 중이시라면, 먼저 테스트 조건 통제부터 챙겨보세요. 그게 반은 먹고 들어갑니다. 진짜로요.