ระบบไฟล์ทำงานอย่างไร: inode, journaling, และ page cache?

Question

IT Interview Practice · Accepted Answer

**ระบบไฟล์ (filesystem)** เปลี่ยนอาร์เรย์แบนราบของ disk block ให้กลายเป็นลำดับชั้นของไฟล์และไดเรกทอรี โดยจัดการ metadata และพื้นที่ว่างเพื่อให้สิ่งนั้นทั้งเชื่อถือได้และรวดเร็ว

## Inode: ไฟล์คือ metadata + พอยน์เตอร์ block

ในระบบไฟล์ UNIX ทุกไฟล์คือ **inode** (index node) — โครงสร้างที่เก็บ **metadata** ของไฟล์ (ขนาด, เจ้าของ, สิทธิ์, timestamp, จำนวน link) และ **พอยน์เตอร์ไปยัง 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** จึงเป็นเพียง entry ไดเรกทอรีตัวที่สองที่ชี้ไปยัง inode เดียวกัน (link count = 2) และทำไม `rm` แท้จริงคือ `unlink` — มันลบชื่อออกและปลดปล่อย inode ก็ต่อเมื่อ link count แตะศูนย์

## Journaling: รอดจาก crash

การทำงานเชิงตรรกะเดียว (เช่นการ append) แตะหลาย block — inode, bitmap พื้นที่ว่าง, ตัวข้อมูล crash กลางคันจะทิ้งระบบไฟล์ไว้ในสภาพไม่สอดคล้อง **journal** จะเขียนการเปลี่ยนแปลงที่ตั้งใจไว้ลง log ก่อน แล้วจึงนำไปใช้ หลัง crash ระบบไฟล์จะเล่นซ้ำ (replay) หรือทิ้ง (discard) journal แทนการสแกนเต็มที่ช้า (`fsck`) โหมดต่าง ๆ แลกความปลอดภัยกับความเร็ว: journal **เฉพาะ metadata** (เร็ว, พบบ่อย) เทียบกับ metadata **และตัวข้อมูล**

## Page cache และเส้นทาง I/O

Kernel cache ข้อมูลไฟล์ไว้ใน 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 เร็ว แต่ข้อมูลที่ "เขียนแล้ว" ยังไม่คงทน (durable) จนกว่าจะ `fsync` ฐานข้อมูลมักใช้ **direct I/O** บวกกับ buffer pool ของตัวเองเพื่อควบคุมการ cache และความคงทนอย่างแม่นยำ

## ทำไมจึงสำคัญ

กลไกภายในของระบบไฟล์อธิบายพฤติกรรมในชีวิตประจำวัน: ทำไม hard link จึงทำงานได้, ทำไมการลบไฟล์ที่โปรเซสยังเปิดค้างอยู่จึงยังไม่คืนพื้นที่จนกว่ามันจะปิด, ทำไม `fsync` จึงจำเป็นต่อความคงทน (และเป็นบั๊กข้อมูลสูญหายคลาสสิกเมื่อละเลยไป), และทำไมการอ่านไฟล์ครั้งที่สองจึงรวดเร็วทันใจ (page cache) วิศวกร senior ให้เหตุผลเกี่ยวกับสิ่งเหล่านี้เมื่อเลือก buffered vs direct I/O สำหรับฐานข้อมูล, กำหนดขนาด RAM สำหรับ cache, หรือ debug ปัญหาความสอดคล้องหลัง crash

Inode: ไฟล์คือ metadata + พอยน์เตอร์ block

Journaling: รอดจาก crash

Page cache และเส้นทาง I/O

ทำไมจึงสำคัญ

คำถามที่เกี่ยวข้อง