왜 파일시스템 선택이 성능 문제로 이어지는가
리눅스 서버에서 ext4는 오랜 기본값이고 XFS는 RHEL 7 이후 기본 파일시스템이다. 둘 다 저널링을 지원하지만 저널링 대상과 동시성 처리 방식이 달라서, 같은 디스크에서도 워크로드에 따라 처리량이 수십 퍼센트 차이 난다. 특히 다수 코어에서 병렬 쓰기가 몰리는 DB나 로그 수집 서버는 파일시스템 락 구조가 병목이 되곤 한다.
저널링 방식의 근본 차이
ext4는 data=ordered(기본), data=writeback, data=journal 세 가지 모드를 제공한다. ordered는 메타데이터만 저널링하되 데이터 블록을 먼저 디스크에 쓴 뒤 커밋하므로 정합성과 성능의 균형이 좋다. journal 모드는 데이터까지 저널에 기록해 안전하지만 모든 쓰기가 두 번 발생한다.
XFS는 메타데이터만 저널링하며 데이터 모드 옵션 자체가 없다. 대신 지연 할당(delayed allocation)과 익스텐트 기반 구조, 그리고 AG(Allocation Group) 단위 병렬화로 멀티코어 확장성을 확보한다. 즉 ext4는 "안전 옵션의 유연함", XFS는 "병렬 확장성"에 강점이 있다.
핵심 특성 비교
| 항목 | ext4 | XFS |
|---|---|---|
| 데이터 저널링 | 지원(journal 모드) | 미지원(메타데이터만) |
| 대용량 파일/볼륨 | 양호 | 우수(익스텐트, 페타바이트급) |
| 병렬 쓰기 확장성 | 제한적 | 우수(AG 병렬) |
| 온라인 축소(shrink) | 불가(오프라인만) | 불가 |
| 작은 파일 다수 | 우수 | 보통 |
워크로드별 선택 기준
- DB(PostgreSQL/MySQL), 대용량 순차·병렬 I/O: XFS. 익스텐트와 AG 병렬화가 유리하고, DB가 자체적으로 fsync 정합성을 보장하므로 데이터 저널링이 불필요하다.
- 메일 서버, 캐시 등 작은 파일 대량: ext4. inode 밀도와 소파일 처리가 안정적이다.
- 로그/미디어 스트리밍, 대용량 append: XFS. 지연 할당이 단편화를 줄인다.
- 축소가 필요한 볼륨: 둘 다 온라인 축소가 안 되지만 ext4는 오프라인 축소가 가능하므로 유연하다.
실전 설정: 마운트 옵션
XFS는 대부분 기본값이 최적이지만, 배터리 백업 컨트롤러가 있다면 무리 없이 성능을 얻을 수 있다. ext4는 워크로드에 맞춰 저널 모드를 조정한다.
# XFS: 포맷 시 로그 크기 지정, 마운트는 noatime 정도만
mkfs.xfs -f -l size=128m /dev/nvme0n1p1
mount -o noatime,nodiratime /dev/nvme0n1p1 /data
# ext4: DB 데이터 볼륨은 writeback + noatime로 저널 오버헤드 감소
# (DB가 fsync로 정합성 보장한다는 전제)
tune2fs -o journal_data_writeback /dev/sdb1
mount -o noatime,data=writeback /dev/sdb1 /var/lib/pgsql
fstab에 고정할 때는 UUID 기반으로 지정한다.
# /etc/fstab
UUID=$(blkid -s UUID -o value /dev/nvme0n1p1) /data xfs noatime,nodiratime 0 0
UUID=$(blkid -s UUID -o value /dev/sdb1) /var/lib/pgsql ext4 noatime,data=writeback 0 0
검증: 정합성과 성능을 함께 확인
설정 후에는 실제 fsync 성능과 정합성을 확인해야 한다. 아래는 fio로 DB 유사 쓰기 패턴을 측정하는 예다.
# fsync 포함 랜덤 쓰기(DB 유사) 측정
fio --name=dbtest --directory=/data --rw=randwrite \
--bs=8k --size=4G --numjobs=4 --iodepth=16 \
--fsync=1 --direct=1 --group_reporting
# XFS 조각화 상태 확인(값이 높으면 재정렬 검토)
xfs_db -r -c "frag -f" /dev/nvme0n1p1
주의점
첫째, data=writeback는 크래시 시 최근 데이터가 유실될 수 있으므로 fsync를 신뢰할 수 있는 애플리케이션(DB)에만 적용한다. 일반 파일 서버에는 ordered를 유지한다. 둘째, XFS는 온라인 확장(xfs_growfs)만 되고 축소가 불가능하므로 볼륨 설계 시 여유 산정이 필요하다. 셋째, barrier 옵션을 임의로 끄는 것은 배터리 백업이 확실한 환경이 아니면 정합성을 해치므로 피한다. 마지막으로 벤치마크는 반드시 실제 워크로드 패턴(블록 크기, 병렬도, fsync 빈도)으로 재현해 판단해야 한다.