문제 24 — 저장 I/O 내구성: 페이지 캐시·write-back·fsync/fdatasync·O_DIRECT

게임 서버가 캐릭터 저장, 재화 원장, 로그를 디스크(또는 DB) 에 기록한다. "저장했다"고 응답한 직후 서버가 크래시(또는 정전)하면, 되살아났을 때 그 저장이 정말 남아 있어야 한다. 그런데 단순히 write() 만 호출하고 응답하면 크래시 후 데이터가 사라질 수 있다.

다음을 설명하라.

1. write() 이후 데이터의 여정: 애플리케이션이 write() 를 호출하면 데이터는 곧바로 디스크에 가는가? 페이지 캐시(page cache)와 write-back(지연 기록)이 무엇이며, write() 가 반환됐다는 것이 내구성(durability)을 의미하지 않는 이유는?

2. fsync / fdatasync: 내구성을 얻으려면 무엇을 호출해야 하는가? fsync 와 fdatasync 의 차이는? 파일 데이터뿐 아니라 디렉터리 엔트리도 fsync 해야 하는 경우(새 파일 생성)를 설명하라.

3. 디스크 쓰기 캐시와 배리어: 디스크(HDD/SSD) 자체의 휘발성 쓰기 캐시가 fsync 의 내구성 보장을 어떻게 깨뜨릴 수 있는가? write barrier / FUA / 배터리·커패시터 백업 캐시(BBU)가 왜 필요한가?

4. O_DIRECT 와 페이지 캐시 우회: O_DIRECT 는 무엇을 우회하며 언제 쓰는가? DB 가 자체 버퍼 풀을 두고 O_DIRECT 를 쓰는 이유, 그리고 O_DIRECT 가 내구성(fsync 필요 여부)과 정렬 제약에서 갖는 함의는?

5. 게임 서버 설계 적용: 재화 원장처럼 유실이 치명적인 쓰기와, 이동 로그처럼 약간 유실돼도 되는 쓰기를 어떻게 다르게 다룰 것인가? WAL(write-ahead log)·그룹 커밋·fsync 배칭이 내구성과 처리량(지연) 사이에서 어떤 트레이드오프를 주는지, RPO 개념과 함께 논하라.