Tổng kết module — Lưu trữ & Filesystem

TL;DR: Module này bóc bảy khái niệm nối nhau thành một chuỗi: cơ chế vật lý quyết định độ trễ, kiểu truy cập quyết định bạn trả khoản đó mấy lần, filesystem quyết định tên file tìm ra dữ liệu bằng cách nào, page cache quyết định lần đọc nào chạm đĩa, fsync quyết định lúc nào dữ liệu thật sự bền, và tầng lưu trữ quyết định giả định nào của bạn còn đứng vững. Đây là một trang để đánh dấu và quay lại.

Đã đi qua những gì

Bạn bắt đầu từ ba khối vật liệu khác nhau — đĩa từ quay, NAND flash, và cái nhãn NVMe hoá ra chỉ là giao thức — rồi thấy mọi con số hiệu năng đều là hệ quả suy ra được từ đó chứ không phải ma thuật của nhà sản xuất. Từ đó bạn leo dần lên: kiểu truy cập, lớp ánh xạ của filesystem, tầng đệm của kernel, ranh giới độ bền, và cuối cùng là chuyện gì xảy ra khi cả cái ổ đĩa nằm ở đầu bên kia một sợi cáp mạng. Bài lab khép lại bằng cách bắt bạn tự đo — vì một con số bạn tự tay lấy được đáng giá hơn mười bảng thông số đọc trên mạng.

🗺️ Cheat sheet

📖 Glossary module

⚠️ Pitfall tổng hợp

❌ Benchmark ổ đĩa mà không xoá page cache → ✅ Xoá cache trước mỗi lượt đo, hoặc dùng --direct=1 với fio. Không làm vậy thì bạn đang đo RAM, sai tới vài bậc độ lớn.

❌ Tin write() trả về là dữ liệu đã bền → ✅ Nó mới chỉ vào page cache; mặc định trang bẩn được phép nằm lại tới 30 giây. Muốn bền thì fsync, và phải kiểm tra giá trị trả về.

❌ fsync file mà quên fsync thư mục sau rename → ✅ Mở thư mục cha rồi fsync chính nó. Thiếu bước này, mất điện có thể xoá sạch cả file cũ lẫn file mới.

❌ Gọi fsync sau mỗi bản ghi cho chắc → ✅ Chi phí nhân theo số lần chờ, không theo số byte. Gom nhiều thay đổi rồi đồng bộ một lần, đúng cách database làm với write-ahead log.

❌ Dùng %util để kết luận NVMe bão hoà → ✅ Với thiết bị nhiều hàng đợi song song, chỉ số đó mất ý nghĩa. Xem độ trễ mỗi thao tác và độ sâu hàng đợi thực tế.

❌ Bê pattern ghi tạm rồi rename lên object storage → ✅ Ở đó không có rename nguyên tử. Ghi khoá mới có phiên bản rồi cập nhật một con trỏ duy nhất.

❌ Mount một volume block cho nhiều máy đọc-ghi → ✅ Filesystem giả định nó là chủ sở hữu duy nhất; hai bên cùng ghi là hỏng dữ liệu. Muốn dùng chung thì lên tầng file.

✅ Self-assessment

Bạn đã đạt module này nếu trả lời được:

• So sánh được HDD, SSD và NVMe về cơ chế vật lý và hệ quả lên độ trễ, IOPS, tuổi thọ — nếu chưa: đọc lại bài 01 mục 2 và 3.
• Dự đoán được chênh lệch giữa truy cập tuần tự và ngẫu nhiên từ cơ chế thiết bị, và đọc đúng ba chỉ số IOPS, throughput, latency — nếu chưa: bài 02.
• Giải thích được filesystem ánh xạ tên file sang khối dữ liệu qua inode, dentry và block allocation — nếu chưa: bài 03.
• Lần theo được đường một lần write() từ page cache xuống mặt đĩa và quyết định khi nào bắt buộc gọi fsync — nếu chưa: bài 04 và bài 05.
• Chọn được giữa block, file và object storage dựa trên độ trễ và ngữ nghĩa nhất quán của workload — nếu chưa: bài 06.

Chưa chắc mục nào thì cách kiểm tra thật nhất là mở lại bài lab và đo. Số liệu tự tay lấy được sẽ nói cho bạn biết mình hiểu tới đâu.

🚀 Tiếp theo

Module sau đổi câu hỏi. Ở đây bạn hỏi dữ liệu nằm ở đâu; module Đường đi I/O & GPU hỏi dữ liệu đi đường nào để tới được biến trong chương trình. Bạn sẽ lần theo một lệnh read() xuyên hết các tầng — syscall, VFS, page cache, block layer, driver, rồi tới thiết bị và ngắt báo xong — và gặp lại chính page cache của module này ở đúng vị trí của nó trên tuyến đường.

Module đó cũng trả một lời hứa treo từ course đầu tiên của track: bài von Neumann từng nói "chi tiết trong bài sau về I/O", và bài sau đó chính là bài mở màn module 02.

📚 Tài liệu mở rộng

• SPDK — NAND Flash SSD Internals — cấp thấp về erase-before-write, FTL và over-provisioning.
• fsync(2) — man7.org — nguồn chính chủ cho khác biệt fsync với fdatasync, và yêu cầu fsync thư mục.
• Linux kernel — sysctl/vm — bốn ngưỡng điều khiển write-back của page cache.
• Linux kernel — writeback cache control — REQ_PREFLUSH và REQ_FUA ở tầng block.
• fio documentation — mọi tuỳ chọn cần cho việc đo lại nghiêm túc hơn bài lab.

Bài tiếp theo: Tổng quan module — Đường đi I/O & GPU