ext4와 XFS는 서버에서 어떤 차이가 있을까? 파일시스템 선택 기준

리눅스 서버를 구축할 때 반드시 결정해야 하는 요소 중 하나가 파일시스템이다. Linux에서는 ext4와 XFS가 대표적으로 사용되지만, 두 파일시스템의 차이를 정확하게 이해하지 않고 운영체제의 기본 설정을 그대로 사용하는 경우가 많다.

서버에 저장되는 데이터는 단순히 디스크 공간에 기록되는 것이 아니다. 파일 생성, 데이터 쓰기, 메타데이터 변경, 디스크 블록 할당 등 여러 과정을 거쳐 저장된다. 이 과정에서 파일시스템의 내부 구조는 서버의 I/O 처리 성능과 장애 복구 방식에 영향을 준다.

특히 대용량 파일을 지속적으로 저장하는 서버와 작은 파일을 빈번하게 생성하는 서버는 서로 다른 I/O 특성을 가진다. 같은 CPU와 메모리, SSD를 사용하더라도 파일시스템에 따라 응답 지연이나 처리량에 차이가 발생할 수 있다.

이번 글에서는 ext4와 XFS의 내부 구조를 살펴보고, 파일시스템 선택이 서버 성능에 영향을 주는 원인부터 실제 증상, 분석 방법, 해결 방법까지 정리한다.

ext4와 XFS의 성능 차이가 발생하는 원인

파일시스템은 디스크에 데이터를 저장하고 관리하는 소프트웨어 계층이다.

애플리케이션이 파일을 생성하거나 수정하면 Linux Kernel은 파일시스템을 통해 필요한 블록을 할당하고 데이터를 기록한다.

이 과정에서 파일시스템은 다음 작업을 수행한다.

• 파일 데이터를 저장할 디스크 블록 할당
• 파일 크기와 위치를 나타내는 inode 및 메타데이터 관리
• 디렉터리 구조와 파일 이름 관리
• 데이터 변경 사항을 디스크에 반영
• 장애 발생 시 파일시스템의 일관성 복구

ext4와 XFS는 이러한 역할을 수행한다는 점에서는 동일하다.

그러나 디스크 공간을 관리하고 여러 I/O 요청을 처리하는 내부 구조에는 차이가 있다.

ext4는 블록 그룹을 기반으로 디스크 공간과 메타데이터를 관리한다. 안정적인 범용 파일시스템으로 다양한 서버 환경에서 사용된다.

반면 XFS는 Allocation Group이라는 독립적인 할당 영역을 활용한다. 이를 통해 여러 작업이 동시에 디스크 공간을 할당할 때 병렬 처리를 수행할 수 있도록 설계되었다.

이러한 구조 때문에 XFS는 대용량 파일과 높은 I/O 동시성이 요구되는 환경에서 유리할 수 있다.

하지만 XFS가 모든 작업에서 ext4보다 빠른 것은 아니다. 작은 파일을 단일 스레드에서 반복적으로 생성하거나 삭제하는 작업에서는 ext4가 더 좋은 성능을 보이는 경우도 있다.

결국 두 파일시스템의 성능 차이는 파일 크기, 접근 패턴, 동시 실행 스레드 수, 스토리지 성능에 따라 달라진다.

ext4는 파일을 어떻게 저장하고 관리할까?

ext4는 ext2와 ext3에서 발전한 Linux 파일시스템이다.

ext4의 중요한 특징은 블록 그룹 구조와 Extent 기반 블록 관리 방식이다.

블록 그룹은 디스크 공간을 일정한 단위로 나누어 관리하는 구조다. 각 그룹에는 파일 데이터와 inode 등의 메타데이터를 관리하기 위한 영역이 존재한다.

파일을 생성하면 ext4는 파일 데이터를 저장할 공간을 할당하고 해당 위치를 inode에 연결한다.

여기서 Extent는 연속된 디스크 블록을 하나의 범위로 표현하는 방식이다.

예를 들어 파일 하나가 연속된 1,000개의 블록을 사용한다면 각각의 블록 위치를 개별적으로 기록하는 대신 시작 위치와 길이를 통해 관리할 수 있다.

이 방식은 블록 위치를 관리하는 메타데이터의 부담을 줄이는 데 도움이 된다.

또한 ext4는 Delayed Allocation 기능을 사용한다.

애플리케이션이 write() 시스템 호출을 실행했다고 해서 항상 즉시 물리적인 디스크 블록이 결정되는 것은 아니다.

데이터는 먼저 Page Cache에 기록될 수 있으며, 커널은 실제 디스크 쓰기가 이루어지는 시점까지 블록 할당을 지연할 수 있다.

이렇게 하면 여러 쓰기 요청을 모아서 처리하고 연속된 공간을 할당할 가능성을 높일 수 있다.

다만 데이터가 Page Cache에 존재한다는 사실만으로 영구 저장이 보장되는 것은 아니다. 갑작스러운 전원 차단이나 커널 장애에 대비하려면 애플리케이션의 fsync() 사용과 스토리지의 쓰기 보장 특성도 중요하다.

ext4는 이러한 특성을 바탕으로 일반적인 웹서버, 애플리케이션 서버, 소규모 데이터 저장 환경에서 폭넓게 사용된다.

XFS는 대용량 파일과 동시 I/O를 어떻게 처리할까?

XFS는 높은 확장성과 병렬 I/O 처리를 고려하여 설계된 저널링 파일시스템이다.

XFS의 대표적인 특징은 Allocation Group 구조다.

Allocation Group은 파일시스템의 공간을 여러 영역으로 나누어 관리하는 단위다.

각 Allocation Group은 자체적인 공간 관리 구조를 가지므로 서로 다른 영역에서 수행되는 파일 할당 작업이 병렬로 진행될 수 있다.

예를 들어 여러 애플리케이션 스레드가 동시에 새로운 파일을 생성한다고 가정해 보자.

파일시스템 내부에서 모든 공간 할당 작업이 하나의 공유 자원에 집중된다면 잠금 경합으로 인해 처리 지연이 발생할 수 있다.

XFS는 여러 Allocation Group을 활용해 공간 할당 작업을 분산함으로써 이러한 병목을 완화할 수 있다.

물론 모든 작업이 완전히 독립적으로 처리되는 것은 아니다. 동일한 디렉터리나 inode에 집중된 작업에서는 여전히 잠금 경합이 발생할 수 있다.

XFS 역시 Extent 기반 블록 할당과 지연 할당 방식을 활용한다.

대용량 파일을 순차적으로 기록하거나 다수의 스레드가 동시에 I/O를 수행하는 환경에서는 이러한 구조가 높은 처리량을 확보하는 데 도움이 된다.

또한 XFS는 파일시스템 생성 이후 inode를 동적으로 할당하는 구조를 가지고 있다.

이는 파일 생성이 많은 환경에서 중요한 관리상의 차이를 만든다.

그러나 XFS는 파일시스템의 크기를 온라인으로 확장할 수 있는 반면, 기존 파일시스템의 크기를 축소하는 기능은 제공하지 않는다.

따라서 향후 스토리지 용량을 줄여야 할 가능성이 있다면 파일시스템 선택 단계에서 이 제약을 고려해야 한다.

ext4와 XFS의 저널링 방식은 어떻게 다를까?

서버에서 파일시스템을 선택할 때 성능만큼 중요한 요소가 장애 복구다.

ext4와 XFS 모두 저널링 기능을 제공한다.

저널링은 파일시스템의 변경 작업을 로그 형태로 관리하여 비정상 종료 이후 메타데이터의 일관성을 복구하는 데 사용하는 기술이다.

하지만 저널링이 모든 파일 데이터의 유실을 방지하는 것은 아니다.

ext4는 대표적으로 다음 세 가지 데이터 저널링 모드를 지원한다.

data=ordered

일반적으로 사용되는 기본 모드다.

메타데이터를 저널에 기록하며, 관련 데이터 블록이 메타데이터 저널 커밋보다 먼저 기록되도록 순서를 관리한다.

data=writeback

메타데이터를 저널링하지만 관련 파일 데이터의 기록 순서는 보장하지 않는다.

장애 발생 시 최근 변경한 파일에 이전 데이터가 나타날 위험이 있다.

data=journal

파일 데이터와 메타데이터를 모두 저널에 기록하는 방식이다.

데이터 기록 경로에 추가 작업이 발생하므로 성능 부담이 커질 수 있다.

XFS는 기본적으로 메타데이터 저널링을 사용하는 구조다.

파일 생성과 삭제, inode 변경 등의 메타데이터 작업을 로그에 기록하고 장애 발생 시 이를 복구에 활용한다.

따라서 ext4와 XFS 모두 비정상 종료 이후 파일시스템 구조를 복구할 수 있지만, 애플리케이션이 최근 기록한 데이터 자체의 영구 저장까지 자동으로 보장하지는 않는다.

데이터베이스처럼 기록 순서와 내구성이 중요한 프로그램에서는 파일시스템뿐 아니라 WAL, fsync(), 스토리지 캐시 정책까지 함께 고려해야 한다.

파일시스템 차이가 실제 서버에서 나타나는 증상

파일시스템 특성이 서버 성능에 영향을 주면 다양한 형태의 증상이 발생할 수 있다.

대표적인 사례를 살펴보자.

작은 파일을 반복적으로 생성하는 서버

웹 애플리케이션이 캐시 파일이나 임시 파일을 지속적으로 생성한다고 가정해 보자.

이 환경에서는 파일 데이터 쓰기뿐 아니라 inode 생성, 디렉터리 갱신, 메타데이터 기록이 빈번하게 발생한다.

특히 단일 스레드 중심의 작은 파일 생성·삭제 작업에서는 XFS보다 ext4가 더 좋은 성능을 보일 수 있다.

그러나 파일 생성이 여러 스레드에 분산되고 스토리지의 I/O 병렬성이 높다면 결과가 달라질 수 있다.

대용량 로그 파일을 기록하는 서버

대규모 서비스에서 수백 MB 또는 수 GB 단위의 로그 파일을 지속적으로 기록하는 상황을 생각해 보자.

이 경우에는 작은 파일 생성 횟수보다 순차 쓰기 처리량과 여러 프로세스의 동시 I/O 특성이 중요해진다.

XFS는 이러한 대용량·병렬 쓰기 환경에서 유리한 성능을 제공할 가능성이 있다.

다만 파일시스템을 변경한다고 해서 느린 디스크 자체의 성능 한계가 해결되지는 않는다.

디스크 공간은 남아 있는데 파일 생성이 실패하는 서버

다음과 같은 오류가 발생하는 경우도 있다.

No space left on device

이 오류는 반드시 디스크의 데이터 저장 공간이 부족할 때만 나타나는 것은 아니다.

ext4에서는 사용 가능한 inode가 소진되면 디스크 공간이 남아 있어도 새로운 파일을 생성하지 못할 수 있다.

XFS 역시 inode 및 메타데이터 할당에 필요한 공간이나 파일시스템 내부 제약으로 인해 공간 부족 오류가 발생할 수 있다.

따라서 단순히 디스크 사용률만 확인해서는 정확한 원인을 파악하기 어렵다.

서버 재시작 이후 파일시스템 오류가 발생하는 경우

비정상 종료 이후 파일시스템이 정상적으로 마운트되지 않는 경우도 있다.

저널 복구만으로 해결할 수 없는 메타데이터 손상이 발생했을 가능성이 있다.

이때 ext4와 XFS는 사용하는 복구 도구와 절차가 서로 다르다.

무작정 복구 명령어를 실행하면 오히려 데이터 손실 위험이 커질 수 있으므로 파일시스템 종류와 장치 상태를 먼저 확인해야 한다.

Linux 서버에서 ext4와 XFS를 분석하는 방법

실제 서버에서 파일시스템 문제를 분석할 때는 먼저 현재 사용 중인 파일시스템 종류를 확인해야 한다.

파일시스템 종류 확인

df -Th

이 명령어는 파일시스템의 종류와 전체 용량, 사용량, 마운트 위치를 표시한다.

출력 결과에서 Type 항목이 ext4인지 xfs인지 확인하면 된다.

블록 장치와 파일시스템의 관계를 확인하려면 다음 명령어를 사용한다.

lsblk -f

이 명령어는 디스크 및 파티션에 설정된 파일시스템 종류와 UUID, 마운트 위치 등을 보여준다.

inode 사용률 확인

df -i

이 명령어는 파일시스템의 inode 사용 상태를 확인할 때 사용한다.

ext4에서 inode 사용률이 100%에 가까워졌다면 새로운 파일 생성이 실패할 수 있다.

XFS에서는 inode가 동적으로 할당되므로 ext4와 동일한 방식으로 inode 총량을 해석해서는 안 된다.

디스크 I/O 성능 확인

iostat -xz 1

이 명령어는 디스크 장치의 I/O 상태를 1초 간격으로 출력한다.

주요 확인 항목은 다음과 같다.

• r/s, w/s: 초당 읽기 및 쓰기 요청 수
• r_await, w_await: 읽기 및 쓰기 요청의 평균 응답 시간
• aqu-sz: 평균 I/O 큐 길이
• %util: 관측 구간에서 장치가 I/O를 처리한 시간의 비율

특히 await 값이 증가한다면 I/O 요청 완료까지의 시간이 길어지고 있다는 의미다.

다만 await 상승만으로 파일시스템이 원인이라고 단정할 수는 없다.

스토리지 장치의 성능 한계, I/O Scheduler, 애플리케이션의 동기 쓰기 패턴, 가상화 환경의 스토리지 지연 등이 함께 영향을 줄 수 있기 때문이다.

또한 NVMe처럼 높은 병렬 처리 능력을 가진 장치에서는 %util이 100%에 가깝다는 사실만으로 포화 상태라고 판단해서는 안 된다.

파일시스템별 세부 정보 확인

ext4에서는 다음 명령어를 사용할 수 있다.

sudo tune2fs -l /dev/sdb1

파일시스템 기능, inode 수, 블록 크기, 저널 관련 정보를 확인할 수 있다.

XFS에서는 다음 명령어를 사용한다.

sudo xfs_info /data

Allocation Group 개수, 블록 크기, 파일시스템 기능 등의 정보를 출력한다.

여기서 /dev/sdb1과 /data는 예시이므로 실제 서버 환경에 맞게 변경해야 한다.

커널 로그에서 오류 확인

sudo journalctl -k --since "1 hour ago"

출력 결과에서 EXT4-fs, XFS, I/O error 등 파일시스템 및 스토리지 관련 메시지를 확인한다.

파일시스템의 메타데이터 오류나 장치 I/O 오류가 기록되어 있다면 성능 튜닝보다 장애 원인 확인을 우선해야 한다.

ext4와 XFS 성능을 비교할 때 확인해야 할 사항

파일시스템 성능 비교에서 가장 흔한 실수는 서로 다른 조건으로 테스트한 결과를 단순 비교하는 것이다.

예를 들어 ext4는 SATA SSD에서 측정하고 XFS는 NVMe SSD에서 측정했다면 성능 차이를 파일시스템의 영향으로 해석할 수 없다.

정확한 비교를 위해서는 동일한 조건을 유지해야 한다.

비교 항목	확인해야 할 조건
저장장치	동일한 SSD 또는 동등한 스토리지
파일 크기	작은 파일과 대용량 파일 구분
I/O 패턴	순차 읽기·쓰기, 랜덤 읽기·쓰기
동시성	단일 스레드와 다중 스레드 비교
캐시	Page Cache 영향 통제
데이터 보장	fsync 등 동기화 조건 동일
파일시스템 설정	마운트 옵션 및 기능 차이 기록

Linux에서는 fio를 사용해 파일시스템의 I/O 성능을 측정할 수 있다.

예를 들어 테스트 전용 디렉터리에서 순차 쓰기 성능을 측정하려면 다음과 같은 명령어를 사용할 수 있다.

fio --name=seqwrite \
    --directory=/data/test \
    --rw=write \
    --bs=1M \
    --size=2G \
    --numjobs=1 \
    --direct=1 \
    --ioengine=libaio \
    --group_reporting

이 테스트는 1MiB 단위의 순차 쓰기 요청을 사용한다.

실행 결과에서 대역폭(BW), IOPS, 지연 시간 등을 분석할 수 있다.

다만 fio의 합성 벤치마크 결과가 실제 웹서버나 데이터베이스 성능을 그대로 대표하지는 않는다.

또한 direct=1 옵션을 사용하면 일반적인 버퍼링 I/O와 다른 경로로 데이터가 처리되므로 Page Cache를 사용하는 애플리케이션과 결과가 다를 수 있다.

더욱 중요한 것은 작은 파일을 빈번하게 생성하고 삭제하는 워크로드에서는 단순 순차 쓰기 테스트만으로 성능을 판단할 수 없다는 점이다.

따라서 실제 서비스의 파일 크기, 동시 접속 수, 동기화 빈도, 메타데이터 작업량을 재현하는 테스트가 필요하다.

테스트 파일이 기존 데이터를 덮어쓰지 않도록 반드시 별도의 테스트 디렉터리나 장치를 사용해야 한다.

서버 환경에 따라 ext4와 XFS를 선택하는 방법

파일시스템 선택에는 절대적인 정답이 없다.

서버가 처리하는 작업의 특성과 운영 환경에 따라 선택 기준이 달라진다.

서버 환경	우선 검토할 파일시스템	판단 이유
일반적인 소규모 웹서버	ext4	범용성 및 관리 편의성
작은 파일의 단일 스레드 처리	ext4	낮은 동시성의 메타데이터 작업에 유리할 수 있음
대용량 파일 저장 서버	XFS	대용량 파일 처리와 확장성
다중 스레드 I/O 서버	XFS	병렬 할당 구조 활용
대규모 로그 저장 서버	XFS	높은 동시성과 순차 쓰기 처리에 적합할 수 있음
파일시스템 축소가 필요한 서버	ext4	오프라인 축소 지원
일반적인 데이터베이스 서버	실제 테스트 후 결정	데이터베이스 엔진과 스토리지 특성에 따라 차이 발생

예를 들어 작은 규모의 WordPress 서버라면 ext4만으로도 충분한 성능을 제공할 수 있다.

이러한 환경에서는 파일시스템 종류보다 PHP 처리 시간, 데이터베이스 쿼리, 메모리 부족, 디스크 응답 지연이 더 중요한 병목 원인인 경우가 많다.

반대로 대규모 로그 수집 시스템이나 여러 프로세스가 대용량 데이터를 동시에 기록하는 서버라면 XFS를 우선 검토할 수 있다.

Red Hat Enterprise Linux에서도 일반적인 대규모 서버 환경에는 XFS를 권장하며, 특정한 낮은 I/O 처리량이나 단일 스레드 작업 등의 조건에서는 ext4가 적합할 수 있다고 설명한다.

하지만 이는 모든 배포판과 워크로드에 적용되는 절대적인 성능 순위가 아니다.

최종 선택은 실제 애플리케이션을 기준으로 검증해야 한다.

파일시스템 성능 문제를 해결하는 방법

파일시스템 성능 문제가 의심된다고 해서 즉시 ext4를 XFS로 변경하거나 반대로 교체하는 것은 좋은 접근이 아니다.

먼저 병목이 발생하는 계층을 분리해야 한다.

스토리지 장치의 성능 한계 확인

iostat에서 디스크 응답 시간이 지속적으로 높게 나타난다면 저장장치의 처리 능력부터 확인한다.

스토리지 자체가 포화 상태라면 파일시스템을 변경하더라도 성능 개선이 제한적일 수 있다.

파일 생성 및 삭제 패턴 분석

작은 파일이 과도하게 생성되는 환경에서는 불필요한 임시 파일과 캐시 파일의 생성을 줄이는 것이 효과적일 수 있다.

파일시스템의 종류보다 애플리케이션의 파일 관리 방식이 더 큰 영향을 줄 수 있기 때문이다.

동기 쓰기 요청 확인

애플리케이션이 fsync()를 지나치게 자주 호출하면 쓰기 지연이 증가할 수 있다.

이 경우 파일시스템 교체보다 동기화 빈도와 트랜잭션 처리 방식을 점검하는 것이 우선이다.

단, 데이터베이스 등 내구성이 중요한 시스템에서 성능 향상을 위해 fsync()를 무분별하게 비활성화해서는 안 된다.

파일시스템 확장 정책 확인

스토리지 확장이 자주 필요한 서버라면 파일시스템별 크기 조정 방식도 중요하다.

ext4는 파일시스템을 확장할 수 있으며, 지원되는 조건에서는 마운트를 해제한 상태로 축소할 수도 있다.

XFS는 마운트된 상태에서 확장이 가능하지만 파일시스템 자체의 축소는 지원하지 않는다.

따라서 처음부터 필요 이상의 용량을 할당하는 것이 항상 좋은 운영 방식은 아니다.

파일시스템 변경 전 데이터 백업

ext4와 XFS 사이에는 기존 데이터를 유지하면서 파일시스템 형식만 직접 전환하는 일반적인 인플레이스 변환 절차가 없다.

보통 새로운 파일시스템을 생성하고 데이터를 백업에서 복원하거나 별도 스토리지로 이전해야 한다.

또한 mkfs.ext4와 mkfs.xfs는 대상 장치에 새로운 파일시스템을 생성하는 명령어이므로 기존 데이터가 있는 운영 디스크에 실행해서는 안 된다.

파일시스템 오류 복구가 필요한 상황에서도 ext4의 e2fsck와 XFS의 xfs_repair를 구분하여 사용해야 한다.

복구 전에는 장치 상태를 점검하고 가능한 경우 백업 또는 스토리지 이미지를 확보해야 한다.

XFS의 xfs_repair -L 옵션처럼 로그를 강제로 초기화하는 작업은 데이터 손실 위험이 있으므로 일반적인 해결 명령으로 사용해서는 안 된다.

정리

ext4와 XFS는 모두 Linux 서버에서 널리 사용되는 저널링 파일시스템이지만 내부 구조와 운영 특성에는 차이가 있다.

ext4는 블록 그룹과 Extent 기반 구조를 활용하며 범용적인 서버 환경에서 안정적으로 사용할 수 있다. 단일 스레드 중심의 작은 파일 작업이나 파일시스템 축소가 필요한 환경에서도 검토할 가치가 있다.

XFS는 Allocation Group을 활용하는 구조로 대용량 파일과 높은 I/O 동시성이 요구되는 환경에서 강점을 가진다. 반면 파일시스템 축소가 불가능하다는 운영상 제약이 있다.

중요한 것은 파일시스템 종류만으로 서버 성능을 판단하지 않는 것이다.

실제 성능은 파일 크기, I/O 동시성, Page Cache, fsync() 호출 방식, 스토리지 성능과 같은 여러 요소의 영향을 받는다.

서버에서 파일 쓰기가 느려졌다면 먼저 iostat와 커널 로그, 파일시스템 사용 상태를 통해 병목 원인을 확인해야 한다.

그다음 실제 애플리케이션의 I/O 패턴을 기준으로 ext4와 XFS를 비교해야 한다.

결국 올바른 파일시스템 선택은 어느 쪽이 더 빠른지를 결정하는 문제가 아니라, 서버가 처리하는 데이터와 운영 요구사항에 적합한 저장 구조를 선택하는 과정이다.