[질문] Anchovia 5주차

[WhiteBin-bin]

🗓️ 관련 주차

Week05

📌 학습 주제

가상 메모리와 파일 시스템

👤 담당자

전병훈

🔑 주요 키워드

• Virtual Memory
• Demand Paging
• Page Fault
• Page Replacement
• File System
• I/O

🧷 질문 작성 규칙

• 질문은 이슈 본문이 아니라 댓글로 작성합니다.
• 하나의 댓글에는 하나의 질문만 작성합니다.
• 답변은 해당 질문 댓글에 대댓글로 작성합니다.
• 추가 질문이 있다면 같은 댓글 스레드에서 이어서 논의합니다.
• 참고 자료가 있다면 질문 댓글 하단에 함께 첨부합니다.

[cutiepepe2926]

❓ 질문 내용

파일에 write()를 호출해 성공하더라도 데이터가 저장장치에 즉시 기록되는 것은 아닌가요?
그렇다면 fsync()는 언제 사용해야 하는지 궁금합니다.

🧩 헷갈리는 부분

write()가 성공하면 데이터 저장이 완료된 것으로 생각했는데, 실제로는 Page Cache에만 기록된 상태일 수 있다는 부분이 헷갈립니다.
이 상태에서 시스템에 장애가 발생하면 데이터가 사라질 수도 있는지 궁금합니다.

💭 내가 이해한 내용

• write()를 호출하면 데이터가 먼저 Page Cache에 기록될 수 있다.
• Page Cache의 변경된 데이터는 Dirty Page로 관리된다.
• 운영체제는 Dirty Page를 나중에 저장장치에 기록한다.
• fsync()는 변경된 데이터를 저장장치에 반영하도록 요청하는 함수이다.

🎯 원하는 답변 방향

write()와 fsync()가 각각 어느 시점까지 데이터 저장을 보장하는지 설명해 주시면 감사하겠습니다.

🔗 참고 자료

[WhiteBin-bin]

❓ 질문 내용

요구 페이징은 프로그램 실행에 필요한 페이지를 처음부터 모두 RAM에 올리지 않고, 필요할 때만 가져오는 방식이라고 하는데요. 운영체제는 어떤 페이지가 필요한지 어떻게 알고 그때 RAM으로 가져오는 건가요?

🧩 헷갈리는 부분

프로그램이 실행되기 전에는 어떤 코드나 데이터가 필요한지 운영체제가 미리 알기 어려울 것 같습니다. 또 필요한 페이지가 RAM에 없으면 Page Fault가 발생한다고 하는데, 이 과정이 프로그램 오류가 아니라 정상 동작이라는 점도 헷갈립니다.

💭 내가 이해한 내용

요구 페이징은 프로그램 전체를 한 번에 RAM에 올리지 않아서 메모리를 아낄 수 있는 방식이라고 이해했습니다. 프로그램이 실행하다가 아직 RAM에 없는 페이지를 사용하려고 하면 Page Fault가 발생하고, 운영체제가 저장장치나 스왑 공간에서 해당 페이지를 찾아 RAM에 올린 뒤 프로그램을 다시 실행하는 것 같습니다.

🎯 원하는 답변 방향

• 개념 설명
• 동작 흐름 설명
• 예시 기반 설명

🔗 참고 자료

[limhb708]

❓ 질문 내용

LRU 페이지 교체 알고리즘이 이론적으로는 가장 최적 알고리즘에 가깝게 우수하지만
실제 운영체제에서는 막대한 오버헤드 때문에 직접 구현하지 않고 하드웨어의 지원을 받는 Clock 알고리즘으로 근사해서 사용한다고 배웠습니다.
순수하게 LRU를 구현할 때 구체적으로 어떤 오버헤드가 발생하기에 실제 시스템에서 쓰지 못하고 Clock 알고리즘으로 대체하는 것인지 궁금합니다.

🧩 헷갈리는 부분

가장 오래전에 참조된 페이지를 찾기 위해 타임스탬프를 찍거나 큐나 연결 리스트를 이용해 참조될 때마다 맨 앞으로 순서를 옮겨주면 될 것 같은데 이 과정이 왜 하드웨어나 OS에 그토록 감당하기 힘든 큰 부담인 직관적으로 잘 와닿지 않습니다.

💭 내가 이해한 내용

• Demand Paging 환경에서 Page Fault가 발생하여 물리 메모리에 빈 프레임이 없을 경우
  특정 페이지를 스왑 영역으로 쫓아내는 Page Replacement가 발생한다.
• LRU 알고리즘은 가장 오랫동안 참조되지 않은 페이지를 쫓아내는 방식이다.

🎯 원하는 답변 방향

• 예시 기반 설명

🔗 참고 자료

[minzx23]

❓ 질문 내용

journaling과 fsync()는 어떻게 함께 사용되나요?

🧩 헷갈리는 부분

journaling을 하면 fsync()가 필수가 아니라고 생각했는데, 아래 예상 질문을 보니 둘을 어떤 순서로 사용하는지도 중요하다는 내용이 있었습니다. 그래서 이 둘이 어떤 식으로 동작하는지가 헷갈립니다.

💭 내가 이해한 내용

• journaling은 장애가 발생했을 때 복구하기 위한 방법으로 사용된다
• journal이 손상되면 일부 데이터가 사라질 수 있다
• 파일 시스템 영역을 변경하기 전 journal에 변경 내용을 트랜잭션 형태로 기록해놓고 기록 내용을 commit한 후 실제 시스템 영역에 변경 내용을 반영하는 형식이다

🎯 원하는 답변 방향

• 동작 흐름 설명

🔗 참고 자료

[Anchovia]

@cutiepepe2926](https://github.com/cutiepepe2926) 질문에 대한 답변 드립니다 !

결론부터 말하면, 일반적인 Buffered I/O에서 write()의 성공은 데이터가 저장장치에 영구적으로 기록되었다는 의미가 아닙니다 !

write()는 데이터를 커널에 전달하는 역할이고, 실제 디스크나 SSD까지의 반영을 기다리고 싶다면 fsync()가 필요합니다.
Linux의 write(2) 문서에서도 성공한 write()가 데이터의 디스크 반영을 보장하지 않는다고 명시하고 있습니다.

1. write()를 호출하면 실제로 어디까지 저장되는가 ?

일반적인 Linux의 Buffered I/O에서는 다음과 같은 흐름으로 동작할 수 있습니다.

Application
    |
    | write(fd, data, size)
    v
Kernel
    |
    v
Page Cache
    |
    | Dirty Page로 표시
    v
write() 반환
    .
    .
    . 커널이 나중에 Write-back
    .
    v
File System / Device Driver
    |
    v
SSD / HDD

예를 들어 다음 코드를 실행했다고 가정하겠습니다.

write(fd, "hello", 5);

write()가 성공하면 일반적으로 "hello" 데이터가 커널의 Page Cache에 반영되고 해당 페이지가 Dirty Page 상태가 될 수 있습니다.
하지만 이 시점에는 아직 SSD나 HDD에 실제 데이터가 기록되지 않았을 수 있습니다. 즉, write() 성공은 영구 저장 완료가 아닙니다.
Linux는 성능을 높이기 위해 매번 write()가 호출될 때마다 저장장치의 완료를 기다리지 않고, Dirty Page들을 모아 나중에 Write-back할 수 있습니다.

2. 그렇다면 write() 성공은 무엇을 의미하는가 ?

간단하게 표현하면, 커널이 해당 쓰기 요청을 받아들였다는 의미에 가깝습니다.
따라서 프로그램이 이어서 같은 파일을 읽으면 새롭게 작성한 데이터를 볼 수 있지만, 이것과 전원 장애 이후에도 데이터가 남아 있는 것은 다른 문제입니다.

또한 write()는 요청한 바이트보다 적은 수의 바이트만 기록하는 Partial Write도 가능하기 때문에 반환값도 확인해야 합니다.

3. Page Cache에만 있는 상태에서 장애가 발생하면 어떻게 되나 ?

여기서는 프로세스 장애와 시스템 장애를 구분하는 것이 좋습니다.

3-1. 프로세스만 종료된 경우

Process
   X 종료

Kernel
 |
 +--- Page Cache의 Dirty Page는 여전히 존재
 |
 +--- 이후 Write-back 가능

프로세스가 죽었다고 Page Cache까지 같이 사라지는 것은 아닙니다.
Page Cache는 프로세스 메모리가 아니라 커널이 관리하는 메모리이기 때문입니다.
따라서 프로세스만 비정상 종료되고 운영체제는 정상적으로 동작하고 있다면, 이미 write()된 데이터가 이후 저장장치에 기록될 수 있습니다.

3-2. 시스템 전체가 갑자기 종료된 경우

write()
   |
   v
Page Cache
   |
   | 아직 Write-back 되지 않음
   |
   X  전원 장애

Page Cache는 RAM에 존재하므로 전원이 갑자기 끊기거나 커널이 크래시하면 아직 저장장치로 내려가지 않은 Dirty Page의 데이터는 손실될 수 있습니다.
따라서 데이터베이스, 로그, 결제 정보처럼 장애가 발생해도 반드시 남아 있어야 하는 데이터라면 단순히 write()의 성공만 믿어서는 안 됩니다.

이때 사용하는 것이 fsync()입니다.

예를 들어 다음과 같이 사용할 수 있습니다.

write(fd, data, size);
fsync(fd);

동작을 단순화하면 다음과 같습니다.

write()
   |
   v
Page Cache
   |
   v
Dirty Page

fsync(fd)
   |
   v
Dirty Data + 필요한 Metadata 쓰기
   |
   v
Storage Device
   |
   v
I/O 완료 대기
   |
   v
fsync() 반환

Linux의 fsync()는 해당 파일의 변경된 데이터를 저장장치로 보내고 파일을 복구하는 데 필요한 메타데이터도 동기화하며 장치가 완료를 보고할 때까지 대기합니다.
저장장치에 캐시가 존재한다면 이를 flush하는 과정도 포함하도록 정의되어 있습니다.

따라서 "write() 반환 -> 데이터가 커널에 반영됨", "fsync() 반환 -> 해당 파일의 변경 내용이 영구 저장장치에 반영되도록 동기화가 완료됨"라고 구분하면 될 것 같습니다 !

4. 그렇다면 모든 write() 뒤에 fsync()를 호출하면 될까 ?

가능하지만 일반적으로는 성능이 매우 떨어질 수 있습니다.

예를 들어

write(fd, data1, ...);
fsync(fd);

write(fd, data2, ...);
fsync(fd);

write(fd, data3, ...);
fsync(fd);

처럼 매번 fsync()를 호출하면 애플리케이션이 저장장치의 실제 I/O 완료를 계속 기다려야 합니다.

Buffered I/O의 장점 중 하나가 여러 쓰기를 메모리에 모아 효율적으로 처리하는 것인데, 매번 동기화를 강제하면 이 장점을 상당 부분 잃게 됩니다.
따라서 일반적으로는 “이 시점 이전의 데이터는 장애가 발생하더라도 반드시 보존되어야 한다”라는 지점에서 fsync()를 사용합니다.

예를 들면 다음과 같습니다.

로그 여러 건 작성
write()
write()
write()
     |
     v
중요한 체크포인트
     |
     v
fsync()

데이터베이스의 WAL(Write-Ahead Log), 트랜잭션 로그, 중요 설정 파일, 금융 데이터 등이 대표적인 사례입니다.

5. 한 가지 추가로 주의할 점

fsync(file_fd)가 성공했다고 해서 해당 파일 이름을 포함하는 디렉터리 엔트리까지 반드시 영구 저장되었다는 의미는 아닙니다.

예를 들어 새로운 파일을 생성한 경우에는

directory
   |
   +--- "data.txt" → inode

라는 디렉터리 정보도 변경됩니다.

Linux fsync(2) 문서에서는 파일에 대한 fsync()만으로는 그 파일이 들어 있는 디렉터리 엔트리의 저장까지 보장하지 않으며, 그것까지 확실히 동기화하려면 디렉터리 자체에도fsync()가 필요할 수 있다고 설명합니다.

그래서 장애에 매우 민감한 프로그램에서는 단순히 write → fsync 만 보는 것이 아니라

파일 작성
→ fsync(file)
→ rename 등의 메타데이터 변경
→ fsync(directory)

처럼 파일과 디렉터리의 내구성까지 고려하기도 합니다.

참고 자료

• Linux man-pages — write(2)
• Linux man-pages — fsync(2)