파일시스템은 어떻게 동작하는가: inode, journaling, page cache

Question

IT Interview Practice · Accepted Answer

**파일시스템(filesystem)**은 평평한 디스크 block 배열을 파일과 디렉터리의 계층으로 바꾸며, 그것을 신뢰성 있고 빠르게 만들기 위해 메타데이터와 여유 공간을 관리한다.

## Inode: 파일은 메타데이터 + block 포인터

UNIX 파일시스템에서 모든 파일은 **inode**(index node)다 — 파일의 **메타데이터**(크기, 소유자, 권한, 타임스탬프, 링크 수)와 **데이터 block으로의 포인터**를 담는 구조. inode가 저장하지 *않는* 것에 주목하라: **파일명**. 이름은 **디렉터리** 안에 있으며, 디렉터리는 그저 이름 → inode 번호를 매핑하는 파일이다:

```text
directory "docs"                  inode 1042              data blocks
┌───────────────────┐            ┌──────────────┐         ┌────────┐
│ "report.txt" →1042│───────────▶│ mode, uid    │──ptr───▶│ block  │
│ "notes.txt"  →1050│            │ size, times  │──ptr───▶│ block  │
└───────────────────┘            │ link count=2 │         └────────┘
                                 │ block ptrs   │──(indirect)──▶ ...
                                 └──────────────┘
```

이것이 **hard link**가 같은 inode를 가리키는 두 번째 디렉터리 엔트리에 지나지 않는(link count 2) 이유이고, `rm`이 실제로는 `unlink`인 이유다 — 이름 하나를 제거하고 link count가 0에 닿을 때만 inode를 해제한다.

## Journaling: crash에서 살아남기

하나의 논리 연산(예: append)은 여러 block을 건드린다 — inode, 여유 공간 bitmap, 데이터. 도중에 crash가 나면 파일시스템은 비일관 상태로 남는다. **journal**은 먼저 의도한 변경을 로그에 기록한 뒤 적용한다. crash 후에는 느린 전수 스캔(`fsck`) 대신 journal을 재생(replay)하거나 폐기(discard)한다. 여러 모드가 안전성과 속도를 맞바꾼다: **메타데이터만** journaling(빠르고 흔함) 대 메타데이터 **와 데이터 모두**.

## Page cache & I/O 경로

kernel은 파일 데이터를 RAM의 **page cache**에 캐싱한다. 그래서 재읽기는 메모리에 적중하고, 쓰기는 **버퍼링(buffered)**되어 나중에 flush된다(write-back):

```text
buffered I/O (default): app ↔ page cache ↔ disk   → cached, async writeback, fast re-reads
direct I/O (O_DIRECT):  app ↔ disk                → bypass the cache; DBs manage their own
fsync():                force buffered data to durable storage (required for real durability)
```

buffered I/O는 빠르지만, "쓰여진" 데이터는 `fsync` 전까지 내구성이 없다. 데이터베이스는 종종 **direct I/O**에 자체 buffer pool을 더해 캐싱과 내구성을 정밀하게 제어한다.

## 왜 중요한가

파일시스템 내부는 일상의 동작을 설명한다: 왜 hard link가 작동하는지, 프로세스가 아직 열어 둔 파일을 지워도 그것이 닫힐 때까지 공간이 해제되지 않는 이유, 왜 `fsync`가 내구성에 필수인지(그리고 빠뜨리면 생기는 고전적인 데이터 손실 버그), 그리고 파일의 두 번째 읽기가 즉각적인 이유(page cache). senior 엔지니어는 데이터베이스에 buffered vs direct I/O를 고를 때, 캐시용 RAM 크기를 잡을 때, crash 일관성 문제를 디버깅할 때 이런 것들을 추론한다.

Inode: 파일은 메타데이터 + block 포인터

Journaling: crash에서 살아남기

Page cache & I/O 경로

왜 중요한가

관련 질문