파일시스템

개념

파일을 저장할 때 필요한 정보는 두 가지다. 실제 데이터(파일 내용)와 메타데이터(크기, 권한, 수정 시간, 디스크 어디에 저장됐는지). 파일시스템은 이 둘을 분리해서 관리한다.

inode와 데이터 블록

• inode — 메타데이터를 담는 구조. 파일 하나당 inode 하나
• 데이터 블록 — 파일 내용이 실제로 저장되는 곳

inode가 데이터 블록의 위치를 가리킨다.

inode 42번:
  크기: 8KB
  권한: rw-r--r--
  수정 시간: 2026-04-12
  데이터 위치: [블록 100, 블록 101]

파일을 읽을 때 OS는 inode를 찾아서 메타데이터를 확인하고, inode가 가리키는 데이터 블록에서 실제 내용을 읽는다.

디렉토리와 파일 이름

inode에 파일 이름은 없다. 파일 이름은 디렉토리에 저장된다. 디렉토리도 파일이며, 그 안에 "이름 → inode 번호" 매핑 테이블이 들어있다.

/home/user/ 디렉토리:
  "hello.txt"  → inode 42
  "photo.jpg"  → inode 87
  "docs"       → inode 103

/home/user/hello.txt를 읽을 때:

1. / 디렉토리에서 "home" → inode 찾음
2. /home 디렉토리에서 "user" → inode 찾음
3. /home/user 디렉토리에서 "hello.txt" → inode 42번 찾음
4. inode 42번에서 데이터 블록 위치 확인 → 내용 읽기

하드링크와 심링크

이름과 inode가 분리되어 있기 때문에 하나의 inode에 이름을 여러 개 붙일 수 있다.

• 하드링크 — 같은 inode에 이름을 하나 더 붙이는 것. 둘 다 진짜 파일이고, 하나를 삭제해도 다른 이름으로 접근 가능

ln hello.txt hi.txt
# hello.txt와 hi.txt 둘 다 inode 42번을 가리킴

• 심링크(symlink) — 파일 내용 자체가 원본 파일의 경로 문자열인 별도 파일. 바로가기와 같다. 원본을 삭제하면 심링크가 깨진다

ln -s hello.txt shortcut.txt
# shortcut.txt → "hello.txt"라는 경로를 담고 있음

페이지 캐시와 fsync

파일에 write()를 호출하면 OS가 바로 디스크에 쓰지 않는다. 페이지 캐시(RAM)에 먼저 쓰고 나중에 커널이 디스크에 반영한다.

write() → 페이지 캐시(RAM)에 씀 → "성공" 리턴
                ↓
          (나중에 커널이 디스크에 반영)

다른 프로세스가 같은 파일을 읽어도 페이지 캐시에서 읽으니까 최신 데이터가 보인다. 문제는 페이지 캐시에만 있을 때 전원이 나가면 데이터가 사라진다는 것이다.

fsync()는 페이지 캐시에 있는 데이터를 지금 당장 디스크에 쓰라고 강제하는 함수다. 느리지만 안전하다. DB가 트랜잭션 커밋할 때 fsync를 쓰는 이유가 이것이다.

저널링

파일 수정은 여러 단계가 필요하다 (데이터 블록 수정, inode 갱신 등). 중간에 전원이 나가면 파일시스템이 반쯤 수정된 상태로 남는다.

저널링은 실제 수정 전에 "이런 작업을 할 거야"라는 로그를 먼저 디스크에 기록한다.

1. 저널에 기록: "데이터 블록 수정, inode 갱신 할 거야"
2. 실제 수정 수행
3. 저널에서 해당 기록 삭제

전원이 나가도 부팅 후 저널을 보고 복구할 수 있다. Git 커밋처럼 변경사항을 기록해놓는 것이다. ext4, xfs 같은 Linux 파일시스템이 전부 저널링을 쓴다.

더 보기

• 가상-메모리 — 페이지 캐시도 가상 메모리 위에서 동작
• IO-모델 — 파일 I/O와 네트워크 I/O의 처리 방식