Hành trình một lệnh read() — từ ứng dụng xuống mặt đĩa

TL;DR: Một dòng read(fd, buf, n) trông như một thao tác duy nhất, nhưng bên dưới nó là một chuỗi chặng: chuyển sang chế độ kernel qua syscall, VFS định tuyến tới filesystem đúng loại, tra page cache — và nếu trúng thì hành trình dừng ngay ở đây, chưa hề chạm đĩa. Trượt cache thì mới đi tiếp: filesystem dịch offset trong file thành số hiệu block, block layer gom yêu cầu thành bio rồi xếp vào hàng đợi, driver dựng descriptor cho DMA, thiết bị chuyển dữ liệu vào RAM và phát một ngắt báo xong. Chênh lệch giữa hai kịch bản là ba bậc độ lớn, và nó nằm gọn ở chỗ có trúng cache hay không.

Bạn viết read(fd, buf, 4096). Một dòng. Nhưng đo bằng strace -T thì đôi khi nó trả về sau vài micro-giây, đôi khi sau vài mili-giây — chênh cả nghìn lần với cùng một dòng code, cùng một file. Hai bài trước cho bạn thanh ghi, DMA và ngắt; bài này ráp chúng vào đúng vị trí trên tuyến đường và trả lời vì sao có hai số đo cách xa nhau đến thế.

1. Analogy — một yêu cầu đi qua nhiều cửa

Bạn nộp đơn xin trích lục giấy tờ ở phường. Nhân viên đọc đơn rồi kiểm ngăn kéo ngay cạnh bàn — hồ sơ mới rút hôm qua thường còn nằm đó, và có sẵn thì bạn cầm bản sao về sau hai phút.

Không có thì đơn mới thật sự đi tiếp: xuống bộ phận lưu trữ, tra sổ xem hồ sơ nằm kệ nào, ghép đơn của bạn với mấy đơn khác cùng khu vực cho đỡ phải xuống hầm nhiều lần, rồi cử người đi lấy. Bạn ngồi chờ, và được gọi tên khi hồ sơ lên tới nơi.

2. Hai chặng đầu — vào kernel, rồi hỏi cache trước

read() không phải hàm thường. Nó là syscall: CPU chuyển từ chế độ người dùng sang chế độ kernel, đổi ngăn xếp, rồi kernel chạy code của nó trên chính lõi ấy.

Vào tới kernel, yêu cầu gặp VFS (Virtual File System) — lớp trừu tượng khiến read() chạy như nhau trên ext4, XFS, NFS hay /proc. VFS tra bảng file descriptor xem fd trỏ tới đối tượng nào, rồi gọi hàm read mà filesystem đó đã đăng ký.

Chặng thứ ba mới là chặng quyết định. Trước khi nghĩ tới đĩa, kernel tra page cache xem những trang tương ứng với vùng dữ liệu đang xin đã nằm sẵn trong RAM chưa. Trúng thì kernel chép thẳng từ page cache sang bộ đệm của ứng dụng, read() trả về, và không một yêu cầu I/O nào được sinh ra. Hành trình kết thúc ở đây.

Đây chính là page cache của bài module trước, giờ hiện ra ở đúng vị trí của nó: một cổng rẽ nằm rất sớm, và mọi thứ phía sau chỉ chạy khi cổng ấy đóng.

3. Chặng giữa — block layer gom việc lại trước khi làm

Trượt cache thì filesystem phải trả lời một câu cụ thể: byte thứ 8192 của file này nằm ở block nào? Với ext4 hay XFS, câu trả lời tra ra từ extent trong inode — cấu trúc bạn đã gặp ở bài filesystem và inode.

Có số block rồi, kernel dựng một bio: đọc hay ghi, bắt đầu từ sector nào, dài bao nhiêu, đổ vào những trang nhớ nào. Đây là đơn vị làm việc chuẩn của block layer, và nó cố tình không nói gì về loại thiết bị bên dưới.

Điều đáng chú ý là block layer không chuyển tiếp bio xuống driver ngay. Nó giữ lại một nhịp, vì ba việc chỉ làm được khi có nhiều yêu cầu trong tay cùng lúc: gộp các yêu cầu liền kề thành một yêu cầu lớn hơn (đáng tiền nhất với ổ quay, vì tiết kiệm một lần seek), sắp xếp lại thứ tự theo chính sách của I/O scheduler, và chia phối vào đúng hàng đợi phần cứng.

Kiến trúc hiện tại là blk-mq (multi-queue), sinh ra vì mô hình một hàng đợi có khoá dùng chung không theo kịp NVMe. Tài liệu kernel mô tả nó thành hai tầng: các hàng đợi staging ở phần mềm, gắn theo CPU nên nhiều lõi xếp yêu cầu mà không giẫm khoá của nhau, rồi đẩy xuống các hàng đợi dispatch ánh xạ vào hàng đợi thật của thiết bị. Mỗi yêu cầu mang một tag, và thiết bị dùng chính tag đó để báo lại yêu cầu nào vừa xong — nhờ vậy hoàn tất mới ra được ngoài thứ tự.

Bộ lập lịch cắm vào tầng này: mq-deadline đặt hạn chót cho mỗi yêu cầu để không ai bị bỏ đói, BFQ chia băng thông theo tiến trình nên hợp máy để bàn, Kyber giữ độ trễ thấp bằng cách siết độ sâu hàng đợi. Với NVMe, nhiều hệ thống bỏ hẳn lập lịch (none) vì thiết bị tự sắp xếp tốt hơn phần mềm.

4. Chặng cuối — driver, DMA và ngắt hoàn tất

Tới đây thì hai bài trước ráp vào. Driver lấy yêu cầu ra khỏi hàng đợi dispatch, dựng descriptor mô tả cần đọc sector nào và đổ vào những trang RAM nào, rồi ghi một giá trị qua MMIO để đánh thức thiết bị.

Sau đó CPU rời đi. Thiết bị tự đọc descriptor và chuyển dữ liệu thẳng vào RAM bằng DMA. Xong việc, nó phát một ngắt; handler tra tag để biết yêu cầu nào hoàn tất, đánh dấu trang trong page cache là hợp lệ, rồi đánh thức tiến trình đang ngủ. Kernel chép từ page cache sang bộ đệm ứng dụng, read() trả về.

Các chặng chênh nhau rất xa — đây là thứ tự độ lớn để so sánh, không phải số đo trên máy cụ thể:

Cột phải cho ngay một kết luận: mọi chặng phần mềm cộng lại vẫn nhỏ hơn hẳn một lần chạm thiết bị. Tối ưu đúng chỗ vì thế hầu như luôn nghĩa là giảm số lần phải xuống tới thiết bị, không phải làm các tầng kernel chạy nhanh hơn.

5. Tự điền — đường về đi ngược lối nào?

Bạn vừa đi hết chiều xuống. Chiều lên thì sao? Điền vào ba ô trống dưới đây trước khi đọc tiếp — mỗi ô một câu, nói rõ ai làm việc đó.

Đáp án. Bước 1: thiết bị tự đổ dữ liệu vào các trang RAM đã ghi trong descriptor bằng DMA, CPU không tham gia — đây là điểm bất đối xứng lớn nhất, vì chiều xuống CPU chủ động ra lệnh còn chiều lên thiết bị chủ động ghi. Bước 2: thiết bị phát ngắt hoàn tất, handler tra tag đi kèm để biết đúng yêu cầu nào vừa xong, vì thứ tự hoàn tất không nhất thiết trùng thứ tự gửi đi. Bước 3: handler đánh dấu trang trong page cache là hợp lệ rồi đánh thức tiến trình; kernel chép từ page cache sang bộ đệm ứng dụng — nghĩa là dữ liệu bị chép hai lần, và chỗ chép thừa này chính là thứ bài zero-copy sẽ cắt.

6. Pitfall của riêng concept này

❌ Nhầm 1 — benchmark read() mà không tính tới page cache.

✅ Lần chạy thứ hai gần như luôn trúng cache, nên con số đo được là tốc độ của RAM chứ không phải của đĩa. Muốn đo thiết bị thật thì phải xoá cache trước mỗi lượt hoặc mở file với O_DIRECT.

❌ Nhầm 2 — tưởng strace thấy read() mất 5 ms nghĩa là thiết bị chậm.

✅ Con số đó gộp cả thời gian nằm chờ trong hàng đợi block layer. Khi độ sâu hàng đợi cao, phần lớn 5 ms có thể là xếp hàng chứ không phải thời gian thiết bị làm việc.

❌ Nhầm 3 — nghĩ đổi I/O scheduler là mẹo tăng tốc chung.

✅ Bộ lập lịch chỉ đổi thứ tự phục vụ, không tạo thêm băng thông. Nó đáng chỉnh khi vấn đề là công bằng hay độ trễ đuôi.

7. 📚 Đào sâu (tuỳ chọn)

8. Liên hệ các bài khác

• Page cache và buffered I/O — cái cổng rẽ ở chặng ba, nhìn kỹ từ bên trong.
• Polling, interrupt và DMA — hai nhân vật của chặng cuối, mổ riêng từng cái.
• Chờ I/O thế nào — bài kế tiếp hỏi tiến trình làm gì trong lúc nằm chờ ở chặng cuối.
• Zero-copy — nhắm thẳng vào lần chép thừa mà mục 5 vừa lôi ra.

9. Tóm tắt

• Chẩn đoán theo thứ tự: thấy hai lần đọc cùng file chênh nhau nghìn lần thì soi page cache trước, đừng vội nghi driver hay đĩa.
• Block layer cố ý giữ yêu cầu lại một nhịp để gộp và sắp xếp; blk-mq chia hai tầng hàng đợi và dùng tag để hoàn tất ngoài thứ tự.
• Mọi chặng phần mềm cộng lại vẫn nhỏ hơn một lần chạm thiết bị, nên tối ưu đúng nghĩa là giảm số lần xuống tới thiết bị.
• Chỗ chép hai lần trên đường về (page cache sang bộ đệm ứng dụng) chính là thứ bài zero-copy sẽ cắt.

10. Tự kiểm tra

Bài tiếp theo: Chờ I/O thế nào — blocking, non-blocking và epoll