Linux 01/09/2026 8 phút

'Đọc tuần tự nhanh hơn ngẫu nhiên' — đo trên SSD thì hai kiểu cho cùng một con số; cái quy tắc ba mươi năm ấy chết cùng cây kim đĩa than, và thứ thật sự quyết định là độ sâu hàng đợi

Quy tắc kinh điển của thiết kế lưu trữ hoá ra là quy tắc của đĩa quay: nó xoay quanh cây kim phải nhấc sang rãnh khác. Trên NVMe không có bộ phận nào chuyển động, nên tuần tự và ngẫu nhiên đo ra bằng nhau. Cái đòn bẩy thật bây giờ là số yêu cầu đang bay cùng lúc — đo được 8,6 lần thông lượng — và có một điểm bão hoà mà vượt qua chỉ làm mọi thứ chậm đi.

Linux 01/09/2026 8 phút

Đổi bộ lập lịch I/O — lời khuyên tinh chỉnh phổ biến nhất — cho đúng 0%: chín lần đo ba bộ lập lịch không cái nào tách khỏi nhiễu; nút thật sự cho 10,7 lần thì gần như không ai đụng tới

Ai cũng khuyên đổi bộ lập lịch I/O cho nhanh. Đo thật trên NVMe: none, mq-deadline, kyber cho cùng một dải IOPS và p99, thứ hạng còn đổi giữa các lần chạy — vì bài toán chúng sinh ra để giải đã biến mất cùng đĩa quay. Trong khi đó read_ahead_kb, cái nút gần như không ai chỉnh, tạo chênh lệch 10,7 lần. Bạn đang chỉnh chỗ sáng, không phải chỗ hỏng.

Linux 01/09/2026 9 phút

Đọc 512 byte tốn đúng bằng đọc 16 KB — ba mươi hai lần dữ liệu, cùng một cái giá; còn căn chỉnh sai với O_DIRECT thì không làm chậm, nó khiến lời gọi hỏng thẳng

Hai câu hỏi hay bị gộp làm một — đọc mỗi lần bao nhiêu byte, và có cần căn chỉnh không — hoá ra là hai câu chuyện khác hẳn. Cái giá của một thao tác I/O nằm ở chính thao tác đó (~35 µs cố định), không ở số byte, nên khối dưới 16 KB là tiền vứt đi. Còn O_DIRECT thì căn chỉnh sai không chậm mà trả EINVAL — và ngưỡng là 512 hay 4096 tuỳ phần cứng, một lớp lỗi chỉ lộ khi đổi ổ.

Linux 01/09/2026 8 phút

Đo một lần, ext4 nhanh gấp 3,2 lần xfs — đo ba lần, con số đó bốc hơi thành nhiễu; bốn phép đo cho bốn thứ hạng khác nhau, và không hệ tệp nào thắng cả bốn

Ba hệ tệp, cùng một máy, cùng một bộ phép đo. Lần chạy đầu tiên cho một tỷ lệ đẹp, dễ nhớ, dễ giật tít — và sai hoàn toàn: chạy lại ba lần thì hai dải trùm lên nhau. btrfs kém rõ ở fsync vì sao chép khi ghi, ext4 ổn định nhất nên vẫn là mặc định cho cơ sở dữ liệu, còn câu hỏi 'hệ tệp nào nhanh hơn' thì không có câu trả lời — phải hỏi nhanh hơn ở việc gì.

Linux 01/09/2026 9 phút

ext4 báo 'hết ổ đĩa' khi vẫn còn trống 71% — nó hết một thứ khác mà df -h không hề nhắc tới, và đây là một trong những sự cố khó chẩn đoán nhất trên máy chủ

Tạo tệp rỗng trên ext4 tới khi No space left on device — mà dung lượng còn dư 71%. Thủ phạm là inode: ext4 chốt cứng số lượng lúc mkfs, hết inode là hết tệp bất kể còn bao nhiêu GB. Cộng thêm bảng đo chi phí stat theo tầng liên kết mềm, trần chuỗi đúng 40, và một sai lầm đo lường tôi tự vấp: stat không đi theo liên kết.

Linux 01/09/2026 9 phút

Đọc 64 byte từ một tệp đã nằm sẵn trong RAM: pread mất 1.019 ns, mmap mất 19 ns — 53 lần, mà không bên nào chạm đĩa; toàn bộ khác biệt là cái giá đi vào nhân

mmap cho phép đọc một tệp như đọc một mảng trong bộ nhớ. Đo thật: với nhiều lần đọc nhỏ ngẫu nhiên trên tệp nóng, mmap nhanh 53 lần vì đọc một byte là đúng một lệnh máy, không lời gọi hệ thống nào. Nhưng nó không phải mặc định — lỗi I/O đến dưới dạng SIGBUS giữa một lệnh truy cập trông vô hại, và đó là lý do SQLite lẫn PostgreSQL từ chối dùng nó cho tệp dữ liệu chính.