# 1. VFS 四大对象 inode、dentry、superblock、file 各自的职责与相互关系是什么？ A 四个对象职责相同 B inode 描述文件元数据，dentry 缓存路径项，file 表示进程打开实例，superblock 描述文件系统全局 ✓ 正确答案 C dentry 描述文件元数据 D file 与 inode 一一对应
# 2. epoll 就绪通知与 io_uring 完成通知的模型差异，completion 直接携带结果为何能减少一次往返，文件系统多阶段操作如何受益？ A 两者完全相同 B epoll 只通知就绪后需再调用取数据，io_uring 完成队列直接携带结果减少往返 ✓ 正确答案 C io_uring 需要更多 syscall D epoll 直接携带结果
# 3. dentry cache（dcache）如何加速路径解析，正负 dentry 分别缓存什么？ A 负 dentry 缓存存在文件 B 正 dentry 缓存存在的目录项，负 dentry 缓存"不存在"结果，都加速路径解析 ✓ 正确答案 C dcache 不缓存路径 D dentry 只用于文件系统挂载
# 4. inode 与 file 为何分离，多个打开文件描述符指向同一 inode 时如何共享与隔离状态？ A 两者保存相同信息 B 偏移存在 inode 中 C file 与 inode 无关 D inode 保存持久元数据，file 保存每次打开的偏移等状态，多打开共享 inode 但偏移独立 ✓ 正确答案
# 5. 硬链接为何只能指向 inode 而不能跨文件系统或指向目录（根目录除外）？ A 硬链接可跨文件系统 B 硬链接可指向任何目录 C 硬链接会创建新 inode D 硬链接是同一 inode 的多个名字，受限于 inode 号只能在文件系统内，且指向目录会破坏树结构故禁止 ✓ 正确答案
# 6. inotify 的事件合并（coalescing）规则，同一 watch 上重复事件如何合并，为什么高吞吐场景需要 fanotify 或 IORING_OP_NOTIFY？ A inotify 对同 watch 重复事件合并、队列满会丢事件，高吞吐场景需 fanotify 或 IORING_OP_NOTIFY ✓ 正确答案 B fanotify 比 inotify 更弱 C inotify 从不丢事件 D IORING_OP_NOTIFY 与事件无关
# 7. superblock 如何描述一个已挂载文件系统的整体信息，挂载点与 superblock 的关系是什么？ A 每个挂载点一个 superblock B superblock 描述文件系统全局信息，挂载点是其在目录树中的入口，同一 superblock 可多次挂载 ✓ 正确答案 C superblock 与挂载无关 D 挂载点属于 inode
# 8. VFS 如何通过操作函数表实现对不同具体文件系统的多态抽象？ A 每个文件系统用不同接口 B VFS 直接操作特定文件系统 C VFS 通过 inode/file/superblock 等操作函数表分发到具体 fs 实现，实现统一接口多态 ✓ 正确答案 D 函数表与多态无关
# 9. io_uring IORING_OP_NOTIFY 集成 inotify / fsnotify / signalfd 的事件通知？ A 它只处理普通 IO B IORING_OP_NOTIFY 把 fsnotify/signalfd 等事件纳入 io_uring 完成队列，统一事件与 IO 处理 ✓ 正确答案 C 事件仍需单独 epoll D 与 signalfd 无关
# 10. inotify event coalescing 在高吞吐写入的工程取舍？ A 合并不丢任何信息 B 高吞吐下 inotify 完全够用 C 合并减少事件量但可能丢失细节，需要精确事件时需增大队列或改用 fanotify/io_uring ✓ 正确答案 D 队列永远不会溢出
# 11. inotify watch descriptor + event mask（IN_CREATE、IN_DELETE、IN_MODIFY）的工程语义？ A wd 表示事件数据 B wd 标识被监控路径，mask 指定事件类型（如 IN_CREATE/IN_MODIFY），目录事件带 name ✓ 正确答案 C 目录事件无 name D mask 只影响性能
# 12. io_uring 的提交/完成队列，与 epoll 相比如何减少 syscall？ A io_uring 与 epoll 相同 B 每个操作都要一次 syscall C io_uring 用共享 SQ/CQ 批量提交与完成，配合 SQPOLL 大幅减少 syscall ✓ 正确答案 D 完成不能批量
# 13. io_uring 的 IORING_OP_NOTIFY 相比传统 signalfd/inotify 事件循环，如何把事件通知纳入同一提交队列以减少系统调用？ A 仍需独立事件循环 B 它与 signalfd 完全等价 C 事件不能进 io_uring 队列 D IORING_OP_NOTIFY 把事件作为 io_uring 完成项返回，与 IO 统一在同一队列，减少 syscall ✓ 正确答案
# 14. inotify 事件队列溢出（IN_Q_OVERFLOW）与事件丢失，如何检测与应对，高吞吐监控为何要增大队列或换方案？ A 队列永不溢出 B 溢出不影响事件 C 队列满触发 IN_Q_OVERFLOW 并丢事件，需增大队列或提高读取，高吞吐换 fanotify/io_uring ✓ 正确答案 D 处理溢出无需重建状态
# 15. io_uring 的超时与取消原语（IORING_TIMEOUT、IORING_OP_ASYNC_CANCEL），如何实现请求级超时与安全取消？ A 取消总是立即成功 B io_uring 不支持超时 C IORING_TIMEOUT 提供超时信号，IORING_OP_ASYNC_CANCEL 取消未完成请求，实现请求级控制 ✓ 正确答案 D 超时与取消无关
# 16. fsnotify 在 fanotify 与 inotify 的继承层次工程价值？ A 三者完全独立 B fanotify 是底层框架 C fsnotify 是底层事件框架，inotify/fanotify 是基于它的用户空间接口并共享事件逻辑 ✓ 正确答案 D fsnotify 与事件无关
# 17. file_operations 与 address_space_operations 的边界在哪里，分别服务于哪类操作？ A 两者职责相同 B address_space_operations 管理打开实例 C file_operations 服务打开的 file 上的读写字调用，address_space_operations 服务 page cache 的页读写 ✓ 正确答案 D file_operations 管理页缓存
# 18. inotify/fanotify 的事件通知，目录监视与审计如何实现？ A inotify 侧重事后通知，fanotify 支持权限事件的事前决策与审计，两者互补 ✓ 正确答案 B 两者完全相同 C fanotify 只能事后通知 D inotify 支持权限决策
# 19. io_uring 的多队列与 NUMA 感知，io-wq 如何调度？ A 只有单队列 B io_uring 支持 per-CPU 多队列与 NUMA 感知，io-wq 是异步 worker 池按 NUMA 调度 ✓ 正确答案 C io-wq 只在单核运行 D NUMA 感知与性能无关
# 20. fanotify 的权限事件（FAN_OPEN_PERM/FAN_ACCESS_PERM），如何实现阻塞式访问决策与审计，与 inotify 异步通知有何差异？ A fanotify 权限事件在访问前阻塞并允许/拒绝决策，inotify 是事后异步通知不决策 ✓ 正确答案 B inotify 会阻塞访问 C 两者都做决策 D fanotify 无法审计
