Hệ thống file hoạt động ra sao: inode, journaling, và page cache?

Question

IT Interview Practice · Accepted Answer

Một **hệ thống file (filesystem)** biến một mảng phẳng các block đĩa thành một cây phân cấp file và thư mục, quản lý metadata và không gian trống để việc đó vừa tin cậy vừa nhanh.

## Inode: một file là metadata + con trỏ block

Trong các filesystem UNIX, mỗi file là một **inode** (index node) — một cấu trúc chứa **metadata** của file (kích thước, chủ sở hữu, quyền, dấu thời gian, số liên kết) và **các con trỏ tới block dữ liệu** của nó. Chú ý cái mà inode *không* lưu: **tên file**. Tên nằm trong **thư mục (directory)**, vốn chỉ là các file ánh xạ tên → số 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)──▶ ...
                                 └──────────────┘
```

Đây là lý do một **hard link** chỉ là một entry thư mục thứ hai trỏ tới cùng một inode (link count = 2), và vì sao `rm` thực chất là `unlink` — nó xóa một cái tên và chỉ giải phóng inode khi link count chạm 0.

## Journaling: sống sót qua crash

Một thao tác logic đơn (ví dụ một lần append) chạm vào vài block — inode, bitmap không gian trống, và dữ liệu. Một cú crash giữa chừng để lại filesystem không nhất quán. Một **journal** trước tiên ghi các thay đổi dự định vào một log, rồi mới áp dụng chúng; sau khi crash, filesystem phát lại (replay) hoặc bỏ (discard) journal thay vì một lần quét toàn bộ chậm chạp (`fsck`). Các chế độ đánh đổi an toàn lấy tốc độ: journal **chỉ metadata** (nhanh, phổ biến) so với metadata **và cả dữ liệu**.

## Page cache & các đường I/O

Kernel cache dữ liệu file trong RAM ở **page cache**, nên các lần đọc lại trúng bộ nhớ và các lần ghi được **đệm (buffered)** rồi flush sau (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 nhanh, nhưng dữ liệu "đã ghi" chưa bền (durable) cho tới khi `fsync`; database thường dùng **direct I/O** cộng với buffer pool riêng để kiểm soát chính xác việc cache và độ bền.

## Tại sao điều này quan trọng

Nội bộ filesystem giải thích các hành vi thường ngày: vì sao hard link hoạt động, vì sao xóa một file mà một process còn đang mở thì chưa giải phóng dung lượng cho tới khi nó đóng, vì sao `fsync` thiết yếu cho độ bền (và là một bug mất dữ liệu kinh điển khi bị bỏ sót), và vì sao lần đọc thứ hai của một file là tức thời (page cache). Kỹ sư senior lý giải những điều này khi chọn buffered vs direct I/O cho một database, định cỡ RAM cho cache, hay debug một vấn đề nhất quán sau crash.

Inode: một file là metadata + con trỏ block

Journaling: sống sót qua crash

Page cache & các đường I/O

Tại sao điều này quan trọng

Câu hỏi liên quan