# ext4

## 개요
**ext4**(Extended File System version 4)는 리눅스 커널에서 널리 사용되는 저널링 파일 시스템으로, ext3의 차세대 아키텍처를 기반으로 한다. 2008년 12월 리눅스 커널 2.6.28에 공식적으로 메인스트림으로 병합되었으며, 이후 서버, 데스크톱, 임베디드 환경까지 아우르는 주요 리눅스 배포판의 기본 파일 시스템으로 자리 잡았다. ext4는 기존 ext2/ext3의 구조적 호환성을 유지하면서 대용량 저장 장치와 대규모 파일을 효율적으로 처리할 수 있도록 설계되었으며, 데이터 무결성 보장과 I/O 성능 최적화를 동시에 추구하는 것이 핵심 목표이다.

## 주요 특징
ext4는 파일 시스템의 안정성, 확장성 및 실시간 성능을 향상시키기 위해 여러 가지 기술적 개선 사항을 도입했다.

### 저널링(Journaling)
저널링은 파일 시스템 메타데이터와 데이터 변경 사항을 실제 저장소에 쓰기 전에 별도의 로그 영역(저널)에 먼저 기록하는 방식이다. 이는 갑작스러운 전원 차단이나 커널 패닉 시 파일 시스템 손상 위험을 크게 줄여준다. ext4는 세 가지 저널 모드를 지원하여 워크로드 특성에 맞게 설정할 수 있다:
- `ordered`(기본값): 메타데이터를 저널링하고, 데이터 변경은 메타데이터 쓰기 전에 정렬된 순서로 저장소에 기록한다.
- `writeback`: 메타데이터만 저널링하며, 데이터 쓰기는 백그라운드에서 비동기적으로 처리된다. 성능이 높으나 시스템 충돌 시 데이터 일관성 위험이 존재할 수 있다.
- `journal`: 메타데이터와 데이터를 모두 저널에 기록한 후 저장소에 적용한다. 가장 안전하지만 I/O 오버헤드가 크다.

### 익스텐트(Extents) 기반 블록 매핑
기존 ext3는 인노드(inode) 내에 직접/간접 블록 포인터를 배열하여 파일의 물리적 위치를 관리했다. ext4는 연속된 데이터 블록을 하나의 `익스텐트`로 묶어 관리하는 방식으로 전환했다. 이는 대용량 파일의 읽기/쓰기 시 탐색 오버헤드를 줄이고, 디스크 단편화 발생 시 블록 재배치 효율성을 크게 향상시킨다.

### 지연 할당 및 다중 블록 할당
파일 쓰기가 요청될 때 즉시 물리적 블록을 할당하지 않고, 가능한 한 많은 데이터를 메모리 버퍼에 모은 후 최적의 위치와 크기로 일괄 할당하는 방식이다. 이는 디스크 접근 횟수를 최소화하고 단편화를 방지하여 전반적인 쓰기 성능을 향상시킨다.

### 온라인 디프레그먼테이션 및 체크섬
`e4defrag` 유틸리티를 통해 파일 시스템을 마운트한 상태에서도 파일의 물리적 배치를 최적화할 수 있다. 또한 메타데이터 변경 사항에 대한 체크섬을 지원하여 데이터 손상을 조기에 감지하며, `fsck` 실행 시간을 기존 파일 시스템 대비 최대 10배 이상 단축한다.

## 기술적 구조 및 제한 사항
ext4는 블록 기반 파일 시스템으로, 기본 블록 크기는 일반적으로 1KB~4KB이며 최대 64KB까지 설정할 수 있다. 인노드 구조는 ext3와 하위 호환되지만, 익스텐트 테이블과 여러 확장 필드가 추가되어 대용량 처리 능력이 크게 향상되었다.

| 항목 | 지원 용량 (기본/최대) |
|---|---|
| 파일 시스템 최대 크기 | 1 TiB / ~1 EiB (커널 버전 및 블록 크기에 따라 다름) |
| 단일 파일 최대 크기 | 16 TiB / ~16 EiB |
| 디렉토리 내 최대 파일 수 | 무제한 (해시 트리 기반) |

*참고: 위 용량은 리눅스 커널 4.1 이상 및 `extent_size`, `metadata_csum` 옵션 활성화 시 적용되는 이론적 한계치입니다.*

ext4는 여전히 안정성 측면에서 검증된 시스템이지만, ZFS나 Btrfs와 같은 차세대 파일 시스템에 비해 내장 RAID, 스냅샷, 투명 압축 등 고급 기능은 제한적이다. 또한 구형 커널에서는 64비트 인노드 확장이 비활성화되어 최대 파일 시스템 크기가 16 TiB로 제한될 수 있으므로, 최신 환경에서는 다음 명령어를 통해 관련 기능을 활성화하는 것이 권장된다.

```bash
# ext4 고급 기능 확인 및 활성화 예시
tune2fs -O extent,uninit_bg,dir_nlink,huge_file,flex_bg /dev/sdX1
```

## 역사 및 채택 현황
ext4는 리눅스 커뮤니티의 핵심 개발자 테오도어 ts'o(Theodore Ts'o)가 주도하여 개발했다. 2008년 커널에 병합된 후, 우분투 10.04 LTS, 레드햇 엔터프라이즈 리눅스 6, 데비안 6 등 주요 배포판이 기본 파일 시스템으로 전환하면서 빠르게 보급되었다. 특히 서버 환경과 임베디드 시스템에서 낮은 오버헤드와 검증된 안정성으로 평가받으며, 안드로이드 운영체제의 내부 저장소 형식으로 오랫동안 사용되었다(최근에는 F2FS 등으로 대체되는 추세).

## 관련 문서 및 참고 자료
- 리눅스 파일 시스템 아키텍처 개요
- ext3 vs ext4 성능 비교 분석
- `e2fsprogs` 유틸리티 공식 문서
- 리눅스 커널 소스 트리 (`Documentation/filesystems/ext4/`)
- man 5 ext4 (리눅스 매뉴얼 페이지)

*본 문서는 리눅스 파일 시스템 기술 문서, 공식 마닐 페이지(man 5 ext4), 및 주요 배포판 기술 백서를 기준으로 작성되었습니다.*

## 성능 최적화 및 마운트 옵션

ext4는 `/etc/fstab`의 마운트 옵션을 통해 워크로드에 최적화된 성능을 낼 수 있다. 특히 I/O 오버헤드를 줄이는 옵션과 I/O 스케줄러(mq-deadline, kyber 등)의 조합이 중요하다.

### 주요 마운트 옵션 및 성능 영향
| 옵션 | 설명 | 성능 영향 | 비고 |
| :--- | :--- | :--- | :--- |
| `noatime` | 파일 읽기 시 액세스 시간(atime) 업데이트를 생략 | **매우 높음** | 쓰기 작업 감소로 SSD/NVMe 수명 및 속도 향상 |
| `relatime` | 특정 조건에서만 atime을 업데이트 (기본값) | 보통 | `atime`보다는 빠르고 `noatime`보다는 안전함 |
| `data=ordered` | 메타데이터 저널링 + 데이터 우선 쓰기 (기본값) | 보통 | 안정성과 성능의 균형점 |
| `data=writeback` | 메타데이터만 저널링, 데이터 쓰기 순서 보장 안 함 | **높음** | 가장 빠르나 충돌 시 데이터 손실 위험 증가 |
| `nodiscard` | TRIM 명령을 실시간으로 보내지 않음 | 낮음 | `fstrim` 주기적 실행과 병행 시 성능 안정적 |

### 마운트 옵션별 벤치마크 (추정치)
*환경: NVMe SSD, 4KB Random Write 기준*

| 마운트 설정 | 처리량 (IOPS) | 지연 시간 (Latency) | 데이터 안정성 |
| :--- | :---: | :---: | :---: |
| `relatime, data=ordered` | 100% (기준) | 1.0x | 높음 |
| `noatime, data=ordered` | 115% $\uparrow$ | 0.9x $\downarrow$ | 높음 |
| `noatime, data=writeback` | 130% $\uparrow$ | 0.7x $\downarrow$ | 낮음 |

## 타 파일 시스템과의 비교

사용 사례에 따라 ext4 외에 다른 파일 시스템이 더 적합할 수 있다.

| 비교 대상 | ext4 대비 강점 | ext4 대비 약점 | 추천 사용 사례 |
| :--- | :--- | :--- | :--- |
| **XFS** | 대용량 파일 처리 및 병렬 I/O 성능 우수 | 작은 파일 생성/삭제 속도 상대적 저하 | 대규모 데이터베이스, 고성능 서버 |
| **Btrfs / ZFS** | 스냅샷, CoW(Copy-on-Write), 내장 RAID, 압축 | 높은 메모리 사용량, 복잡한 관리 구조 | 백업 서버, 가상화 호스트, NAS |
| **F2FS** | 플래시 메모리(NAND) 특성 최적화, 쓰기 증폭 감소 | HDD/SSD 범용성 부족, 전원 차단 시 취약성 | 안드로이드 스마트폰, SD 카드, eMMC |

## 저널 모드별 데이터 손실 시나리오

저널링 모드는 시스템 충돌(Crash) 발생 시 데이터 복구 범위와 일관성을 결정한다.

| 저널 모드 | 작동 방식 | 충돌 시 결과 | 데이터 손실 위험 |
| :--- | :--- | :--- | :--- |
| `journal` | 데이터 $\rightarrow$ 저널 $\rightarrow$ 본 저장소 | 가장 완벽한 복구 가능 | 매우 낮음 |
| `ordered` | 데이터 $\rightarrow$ 본 저장소 $\rightarrow$ 메타데이터 저널링 | 파일 시스템 구조는 유지되나, 최신 데이터 일부 유실 가능 | 낮음 |
| `writeback` | 메타데이터 저널링 (데이터 쓰기 순서 무관) | 파일 시스템 구조는 유지되나, 파일 내부에 이전 데이터(Garbage)가 섞일 수 있음 | 보통 |

## Htree(Hash-based directory indexing) 구조

ext4는 디렉토리 내 파일 수가 수만 개 이상으로 증가할 때 발생하는 선형 탐색 성능 저하를 해결하기 위해 **Htree** 구조를 사용한다.

### Htree 작동 원리
기존의 선형 리스트 방식은 파일을 찾기 위해 처음부터 끝까지 훑어야 했으나, Htree는 파일 이름을 해시(Hash) 값으로 변환하여 B-tree와 유사한 계층 구조로 관리한다.

**[Htree 구조 다이어그램]**
```mermaid
graph TD
    Root[Root Directory Block] --> Hash1[Hash Range A-M]
    Root --> Hash2[Hash Range N-Z]
    Hash1 --> Leaf1[File A, File C]
    Hash1 --> Leaf2[File B, File M]
    Hash2 --> Leaf3[File N, File S]
    Hash2 --> Leaf4[File X, File Z]
```
- **해시 변환**: 파일 이름 $\rightarrow$ 32비트 해시 값.
- **인덱싱**: 해시 값을 기준으로 블록을 분할하여 저장.
- **효과**: 파일 수가 $N$개일 때 탐색 시간이 $O(N)$에서 $O(\log N)$으로 획기적으로 단축되어, 대규모 디렉토리에서도 일정한 응답 속도를 유지한다.

## 플래시 메모리 최적화와 F2FS 전환 배경

과거 안드로이드는 기본 파일 시스템으로 ext4를 채택했으나, 최신 기기들은 **F2FS(Flash-Friendly File System)**로 전환하는 추세이다.

1. **쓰기 증폭(Write Amplification) 문제**: ext4는 HDD 기반의 블록 업데이트 방식을 사용하므로, 작은 데이터를 수정할 때도 주변 블록을 함께 지우고 다시 써야 하는 플래시 메모리의 특성상 수명 단축과 성능 저하가 발생한다.
2. **로그 구조 파일 시스템(LFS)**: F2FS는 데이터를 순차적으로 기록하는 로그 구조를 채택하여, NAND 플래시의 가비지 컬렉션(GC) 효율을 극대화하고 쓰기 성능을 높였다.
3. **결론**: 범용적인 서버/PC 환경에서는 여전히 ext4가 표준이지만, 쓰기 횟수가 제한적인 모바일 스토리지 환경에서는 F2FS가 물리적 특성에 더 적합하기 때문이다.