파일시스템 선택과 마운트 최적화: ext4, XFS, Btrfs

파일시스템 선택이 데이터베이스 성능에 미치는 영향

"파일시스템은 그냥 ext4 쓰면 된다"는 말을 자주 듣는다. 많은 경우 맞다. 그런데 Allegro가 Kafka 클러스터를 ext4에서 XFS로 바꿨을 때 produce 꼬리 레이턴시가 80% 이상 개선되었다. PostgreSQL WAL이 있는 ext4 서버에서 nobarrier 마운트 옵션을 잘못 설정했다가 장애 이후 데이터가 손상된 사례도 있다.

파일시스템은 운영체제와 스토리지 하드웨어 사이의 번역 계층이다. 어떤 번역 계층을 쓰느냐에 따라 동일한 NVMe라도 성능이 달라지고, 동일한 마운트 실수라도 결과가 달라진다.

이 글에서 다루는 내용:

• ext4, XFS, Btrfs의 내부 구조와 각각의 강점·약점
• 데이터베이스별 권장 파일시스템과 그 근거
• 핵심 마운트 옵션의 의미와 안전한 적용 기준

ext4

내부 구조

Extent 기반 블록 관리

ext4 이전(ext3)은 간접 블록 포인터(indirect block pointer)로 파일 위치를 기록했다. 파일이 크면 포인터 체인이 길어지고 메타데이터 접근이 많아진다. ext4는 이를 Extent 방식으로 대체했다.

Extent는 "시작 블록 + 연속 길이"로 표현된다. 4KB 블록 기준 최대 128MB를 extent 하나로 기술할 수 있다. inode 안에 extent 4개까지 직접 저장되고, 그 이상이면 B+ 트리(extent tree)로 확장된다.

저널(Journal)과 세 가지 모드

파일시스템은 쓰기 도중 전원이 나가도 일관된 상태를 유지해야 한다. ext4는 JBD2(Journaling Block Device 2) 저널을 사용한다. data= 마운트 옵션으로 동작 방식을 선택한다.

data=ordered가 기본값이며 대부분의 데이터베이스에 적합하다. InnoDB처럼 자체 더블 라이트 버퍼를 갖는 엔진은 data=writeback을 사용해도 안전하다.

Delayed Allocation(지연 할당)

ext4는 실제 디스크 쓰기 직전까지 블록 할당을 미룬다. 이를 통해 더 큰 연속 extent를 한 번에 할당할 수 있어 단편화를 줄이고 순차 쓰기 성능이 향상된다. 단, fsync() 없이 프로세스가 비정상 종료하면 0으로 채워진 블록이 남을 수 있다. 데이터베이스 엔진은 일반적으로 fsync()를 올바르게 호출하므로 문제가 없다.

Fast Commit (커널 5.10+)

커널 5.10(2020년 11월)부터 도입된 경량 저널 방식이다. 풀 트랜잭션 블록 대신 메타데이터 변경분만 기록한다. data=ordered 기준 fsync 집중 워크로드에서 20~200% 쓰기 성능 향상이 보고되었다.

주요 한계

• 최대 파일 크기: 16 TiB (4KB 블록 기준)
• 최대 볼륨 크기: 1 EiB (이론값; Linux VFS 실질 한계 적용)
• NVMe에서 dioread_nolock 옵션 없이 Direct I/O 시 처리량이 30~80% 낮아지는 문제 있음 (커널 버전 및 하드웨어에 따라 차이 있음)

XFS

내부 구조: 할당 그룹(Allocation Group)

XFS의 핵심은 Allocation Group(AG) 이다. 파일시스템 전체를 여러 AG로 분할하고, 각 AG는 독립적인 lock을 가진다.

각 AG는 독립적인 B+ 트리로 inode·free space·extent를 관리한다. 스레드가 동시에 각자 다른 AG에서 작업하면 lock 경합이 없다. 다중 코어·다중 디스크 구성에서 XFS가 ext4보다 높은 동시 쓰기 처리량을 보이는 근본 이유다.

저널(Log)

XFS 저널은 메타데이터만 기록한다(data=ordered 같은 모드 선택 없음). 저널은 파일시스템 내부(기본) 또는 외부 별도 디바이스에 배치할 수 있다. logbsize(로그 버퍼 크기, 기본 32KB~256KB)와 logbufs(인메모리 버퍼 수, 기본 8)로 튜닝한다.

Speculative Preallocation(투기적 선할당)

파일이 증가 중일 때 XFS는 요청된 크기보다 더 많은 공간을 미리 확보한다. 파일이 닫힐 때 미사용 공간을 해제한다. 이 메커니즘이 대용량 파일 쓰기에서 XFS의 연속 extent 크기를 크게 유지하는 비결이다.

주요 한계

• 볼륨 축소(shrink) 불가 — AG 구조의 구조적 결과
• 최대 파일 크기: 8 EiB (64비트 Linux)
• 최대 파일시스템 크기: 18 EiB

Btrfs

Copy-on-Write(CoW)

Btrfs의 모든 쓰기는 기존 블록을 수정하지 않고 새 위치에 복사본을 만드는 CoW 방식이다. 이를 통해 원자적 쓰기, 즉각 스냅샷, 블록 수준 체크섬을 지원한다.

CoW와 데이터베이스: 왜 문제인가

InnoDB, PostgreSQL처럼 랜덤 업데이트가 많은 엔진은 Btrfs의 CoW와 충돌한다.

• 4KB InnoDB 페이지를 업데이트할 때마다 새 위치에 기록
• 시간이 지나면서 extent 맵 단편화 심화
• 메타데이터 B+ 트리 노드까지 CoW가 연쇄 발생
• 벤치마크 기준 ext4/XFS 대비 10~25% 쓰기 처리량 저하

chattr +C로 CoW 비활성화

# 디렉터리에 적용 (이후 생성되는 파일에 적용)
mkdir /var/lib/mysql
chattr +C /var/lib/mysql

# 기존 빈 파일에 적용
truncate -s 0 /var/lib/mysql/ibdata1
chattr +C /var/lib/mysql/ibdata1

# 확인
lsattr /var/lib/mysql/

중요 제약:

• 이미 데이터가 있는 파일에는 소급 적용 불가 — 반드시 빈 파일에 적용
• nodatacow가 활성화되면 체크섬(nodatasum)이 비활성화됨 → Btrfs의 데이터 무결성 보호가 해당 파일에 작동하지 않음
• 압축과 함께 사용 불가 — +C와 compress= 옵션은 상호 배타적

RAID 프로필 안정성 (2026년 기준)

RAID 5/6는 write hole 문제(전원 장애 시 패리티 불일치)가 아직 해결되지 않았다.

투명 압축

# zstd 레벨 3 압축으로 마운트 (콜드 데이터 볼륨에 적합)
mount -o compress=zstd:3 /dev/sdb1 /data/archive

압축 알고리즘: lzo(가장 빠름), zstd:1~3(추천 균형점), zlib(최고 압축률). 로그·텍스트 데이터가 많은 볼륨에서 쓰기 바이트 감소로 실질적 I/O가 줄어드는 효과가 있다. 단, nodatacow(+C)와 같이 쓸 수 없다.

데이터베이스별 권장 파일시스템

핵심 마운트 옵션 정리

Write Barrier: 언제 비활성화해도 안전한가

저널링 파일시스템은 안전한 커밋을 위해 캐시 플러시(barrier) 명령을 스토리지에 보낸다.

[데이터 플러시] → [저널 커밋 블록 기록] → [커밋 블록 플러시]

이 순서가 보장되지 않으면 전원 장애 후 저널이 일관되지 않은 상태가 될 수 있다.

XFS와 barrier의 역사적 변화:

• 커널 4.10: XFS nobarrier 옵션 deprecated
• 커널 4.19: XFS nobarrier 옵션 완전 제거 (사용 시 마운트 오류)
• 커널 4.13+: XFS가 블록 레이어에 직접 쿼리 — 디바이스가 휘발성 캐시를 가지지 않는다고 보고하면 자동으로 barrier 플러시 생략

따라서 XFS에서는 nobarrier 마운트 옵션을 사용하지 않는다. BBU/PLP 장치에서는 드라이버 레벨에서 write-through를 보고하도록 설정하면 XFS가 자동으로 barrier를 생략한다.

ext4는 여전히 barrier=0 또는 nobarrier를 지원하지만, 확인된 BBU/PLP 없이는 사용하지 않는 것이 원칙이다. Red Hat 공식 문서 기준 barrier 유지 시 성능 페널티는 현대 하드웨어에서 약 3% 수준이다.

권장 fstab 예시

# MySQL InnoDB — ext4 + NVMe
/dev/nvme0n1p1 /var/lib/mysql ext4 defaults,noatime,data=ordered,dioread_nolock 0 2

# MySQL InnoDB — XFS
/dev/nvme0n1p1 /var/lib/mysql xfs defaults,noatime,logbsize=256k,logbufs=8 0 2

# Kafka 로그 — ext4
/dev/sdb1 /var/kafka-logs ext4 defaults,noatime,nodiratime,data=writeback 0 2

# Kafka 로그 — XFS
/dev/sdb1 /var/kafka-logs xfs defaults,noatime,nodiratime 0 2

# ClickHouse — ext4 (공식 권장)
/dev/sdc1 /var/lib/clickhouse ext4 defaults,noatime 0 2

# 아카이브 / 콜드 데이터 — Btrfs + 압축
/dev/sdd1 /data/archive btrfs defaults,noatime,compress=zstd:3 0 2

운영 체크리스트

□ 파일시스템 확인
    df -Th          # 마운트된 파일시스템 타입 확인
    cat /proc/mounts | grep -E 'xfs|ext4|btrfs'

□ ext4 NVMe 서버: dioread_nolock 마운트 확인
    findmnt -O dioread_nolock

□ XFS 저널 버퍼 확인
    xfs_info /var/lib/mysql | grep -E 'log|bsize'

□ atime 비활성화 확인
    findmnt -O noatime

□ nobarrier 잔재 확인 (XFS에서는 커널 4.19+ 에서 오류 유발)
    cat /proc/mounts | grep nobarrier

□ Btrfs 데이터베이스 디렉터리 CoW 상태 확인
    lsattr -d /var/lib/mysql    # 'C' 플래그 확인

□ TRIM 설정 확인 (discard 마운트 옵션 대신 fstrim 사용)
    systemctl status fstrim.timer
    # 없으면 활성화:
    systemctl enable --now fstrim.timer

Open Questions

• ClickHouse에서 ext4 vs XFS 성능 차이에 대한 공식 벤치마크가 아직 존재하지 않는다. 공식 문서는 ext4를 권장하지만, 고 IOPS 환경에서 XFS가 유리할 수 있다는 커뮤니티 보고가 있다.
• XFS speculative preallocation이 특정 워크로드(수백만 개 소형 파일 동시 생성)에서 디스크 공간을 일시적으로 과도하게 점유하는 사례가 보고된다. allocsize 옵션 또는 xfs_io -c "falloc" 후 필요량 명시 방식으로 완화 가능하나, 최적값은 워크로드마다 다르다.

References

• ext4 Documentation — The Linux Kernel
• XFS Documentation — The Linux Kernel
• Btrfs Status — btrfs.readthedocs.io
• Fast Commits for ext4 (LWN.net)
• ClickHouse Server Configuration Tips
• Kafka Hardware and OS Recommendations
• Watch Out for Disk I/O Performance Issues When Running ext4 — Percona
• Write Barrier On/Off — Red Hat Storage Administration Guide
• Btrfs RAID 5/6 Technical Analysis — raidsize.com
• Understanding NAND Types and XFS Performance — Allegro Tech Blog