malloc(500MB) trong container 100MB trả về khác NULL — overcommit đồng ý ngay. Nhưng khi tôi chạm vào bộ nhớ đó, nhân giết tiến trình bằng SIGKILL không bắt được, exit 137, memory.events ghi oom_kill=1. malloc thành công không phải bằng chứng bạn có RAM; cái chết đột ngột lúc dùng mới là sự thật.
Working-set 80MB trong 100MB RAM: 0 major fault, 900.000 MB/s. Đẩy lên 150MB (tràn 54MB ra swap): 9.000 major fault mỗi lần quét, còn 600 MB/s — chậm 1.500 lần. Swap không phải 'thêm RAM' mà là vùng tràn chậm gấp nghìn lần, và cái vực đó vô hình cho tới đúng ngưỡng working-set gặp RAM.
mmap 100GB trên máy 8GB thành công ở chế độ always (Committed_AS lên 101GB) — nhưng cùng lệnh đó trả NULL ở chế độ strict, nơi cả cấp phát 6GB cũng thất bại vì vượt CommitLimit ~5GB. malloc thành công hay không không phải thuộc tính của code bạn hay RAM máy, mà của một sysctl toàn hệ thống.
Hai fd tới cùng một file: tạo bằng dup thì chung offset (đọc fd1 dời luôn fd2, fd2 đọc tiếp 'FGHIJ'), mở hai lần thì offset độc lập (fd2 đọc lại 'ABCDE' từ đầu). Cùng 'hai fd một file', hành vi ngược nhau — biến ẩn là cách chúng ra đời. Đo bằng /proc/fdinfo.
Chạy thử là root, mở file cấm-mọi-quyền vẫn thành công — root bỏ qua mọi bit, kiểm bảo mật khi là root là kiểm không gì cả. Hạ xuống user thường mới ra EACCES. Và nhân kiểm quyền MỘT LẦN lúc open: chmod 000 không thu hồi được fd đang mở, chỉ chặn open mới.
Cùng một tiến trình là PID 1 nhìn từ trong namespace, PID 17 nhìn từ host — inode namespace khác nhau chứng minh đó là hai view của một tiến trình. Container không phải máy ảo: chỉ là tiến trình host với view riêng. Vì sao nhiều 'sự thật' của hệ điều hành là tương đối theo góc nhìn.