建议重点关注的考点

  • Linux 文件系统基础：inode、目录项、文件描述符、挂载
  • I/O 路径与缓存：Page Cache、Buffer、刷盘、fsync
  • 常见文件系统：ext4、xfs
  • 磁盘与卷管理：RAID、LVM、分区扩容
  • 容器存储：overlay2、镜像层、容器可写层
  • K8s 存储对象：PV、PVC、StorageClass、CSI
  • 网络存储与分布式存储：NFS、Ceph、块/文件/对象存储
  • 存储排障：磁盘满、inode 满、I/O 延迟高、挂载异常
Q1：Linux 中文件的 inode、目录项（dentry）、文件描述符（fd）分别是什么？它们之间是什么关系？

  • 核心要点

    • inode 保存文件元数据，如权限、大小、时间戳、数据块位置，但不保存文件名
    • 文件名和 inode 的映射保存在目录项（dentry）中
    • 进程通过文件描述符 fd 引用一个打开的文件对象
    • 典型链路可理解为：进程 -> fd -> file对象 -> dentry -> inode
    • 删除文件时，如果进程还持有打开的 fd，磁盘空间不一定立刻释放

  • 易错点

    • 误以为文件名存在 inode 里
    • 误以为 rm 后空间一定马上释放
    • 把 fd 和 inode 混为一谈，前者是进程级句柄，后者是文件元数据对象

  • 深挖点

    • 为什么日志删了磁盘空间还没回来？——常见原因是进程仍持有该文件句柄
    • 如何排查？——可结合 lsof | grep deleted
    • hard link 本质是多个文件名指向同一个 inode
Q2：什么是 Page Cache？write、flush、fsync 分别意味着什么？

  • 核心要点

    • Page Cache 是内核用来缓存文件数据页的机制，用于减少磁盘 I/O
    • 应用执行 write，通常先写入 Page Cache，并不代表已经真正落盘
    • 内核会在合适时机异步回写脏页到磁盘
    • fsync/fdatasync 用于强制把数据刷到稳定存储，保证持久性
    • 数据库、etcd 等对落盘语义很敏感，面试常会问到

  • 易错点

    • 误以为 write 成功就等于数据已经写到磁盘
    • 误以为 Page Cache 越大越不好，实际上它通常能提高读写性能
    • 不清楚“写入成功”和“持久化成功”的区别

  • 深挖点

    • 为什么数据库喜欢自己控制缓存，而不是完全依赖 Page Cache？
    • 什么是脏页（dirty page）？什么时候触发回写？
    • Direct I/O 和 Buffered I/O 的区别是什么？
Q3：ext4 和 xfs 有什么区别？K8s 节点为什么经常推荐用 xfs？

  • 核心要点

    • ext4 通用性强，生态成熟，恢复工具丰富
    • xfs 在大文件、高并发、并行 I/O 场景下通常表现更好
    • 容器运行时（如 Docker / containerd）在生产中常搭配 xfs
    • xfs 对大容量磁盘、在线扩容支持较好
    • K8s 节点上镜像层、容器层、日志写入较多，xfs 常更合适

  • 易错点

    • 说成“xfs 一定比 ext4 快”，这是不严谨的，要看负载类型
    • 忽略挂载参数和实际业务模式，只背结论
    • 不知道 xfs 常见是支持扩容，不支持缩容

  • 深挖点

    • overlay2 为什么常要求底层文件系统满足特定条件？
    • xfs 的 ftype=1 为什么重要？——对 Docker/overlay2 很关键
    • 文件系统选择要看什么？——小文件/大文件/并发写/恢复要求/工具链
Q4：什么是 RAID、LVM？它们在运维中的作用分别是什么？

  • 核心要点

    • RAID 解决的是磁盘级别的性能、冗余、可用性
    • 常见 RAID：
      • RAID 0：高性能，无冗余
      • RAID 1：镜像，冗余强
      • RAID 5：兼顾容量和冗余
      • RAID 10：性能和可靠性都较好
    • LVM 解决的是逻辑卷管理，方便弹性扩容、卷管理、快照
    • 常见链路：物理磁盘 -> PV -> VG -> LV -> 文件系统 -> 挂载点

  • 易错点

    • 把 RAID 和 LVM 混为一类
    • 误以为 LVM 自带数据冗余，实际上它主要解决管理灵活性
    • 不清楚 RAID 5/6 的写惩罚问题

  • 深挖点

    • 在线扩容一个挂载中的业务盘，一般步骤是什么？
    • 为什么数据库或存储系统常偏好 RAID 10？
    • LVM snapshot 的适用场景与性能影响是什么？
Q5：容器里的数据写到哪里？overlay2 是怎么工作的？

  • 核心要点

    • 容器镜像是只读层，容器启动后会叠加一个可写层
    • overlay2 利用联合挂载，把多个只读层和一个可写层合并成统一视图
    • 容器内对镜像文件的修改，通常会触发 copy-on-write
    • 容器可写层不适合存放重要持久化数据
    • 持久化数据应放在 Volume，如 PVC、hostPath、NFS、Ceph 卷等

  • 易错点

    • 以为容器里写文件天然就是持久化的
    • 不清楚“镜像层”和“容器可写层”的区别
    • 忽略 overlay2 会放大 inode、空间、性能问题

  • 深挖点

    • 为什么容器日志、镜像层容易把节点磁盘打满？
    • copy-on-write 对性能有什么影响？
    • 如何查看容器实际占用的磁盘空间？
Q6：K8s 里的 PV、PVC、StorageClass、CSI 分别是什么？它们之间如何协作？

  • 核心要点

    • PV：集群中的持久卷资源
    • PVC：用户对存储的申请
    • StorageClass：定义存储类型、参数、动态供应方式
    • CSI：K8s 对接不同存储系统的标准接口
    • 典型流程：Pod 使用 PVC -> PVC 绑定 PV -> PV 由 CSI/StorageClass 提供

  • 易错点

    • 把 PV/PVC 当成“磁盘本体”，实际上它们是 K8s 抽象对象
    • 不清楚静态供给和动态供给的区别
    • 不了解 accessModes、reclaimPolicy、volumeBindingMode

  • 深挖点

    • ReadWriteOnce、ReadOnlyMany、ReadWriteMany 分别适合什么场景？
    • WaitForFirstConsumer 为什么重要？
    • CSI Controller 和 Node 插件各负责什么？
Q7：块存储、文件存储、对象存储有什么区别？在 K8s 中怎么选？

  • 核心要点

    • 块存储：以裸块设备形式提供，性能高，常用于数据库
    • 文件存储：以文件系统共享目录形式提供，如 NFS，适合共享读写
    • 对象存储：通过 API 访问，不适合作为传统 POSIX 文件系统盘直接挂载
    • K8s 持久卷里常见的是块存储和文件存储
    • 数据库、etcd 等通常更偏向块存储；共享配置、共享文件更适合文件存储

  • 易错点

    • 把对象存储当成普通磁盘来理解
    • 认为 NFS 一定性能差，实际要看网络、后端、负载模式
    • 不结合应用读写模型盲目选型

  • 深挖点

    • 为什么数据库通常不建议把关键数据直接放 NFS？
    • Ceph RBD 和 CephFS 的差异是什么？
    • 块存储和文件存储在故障恢复、扩容、共享能力上的差异？
Q8：节点磁盘空间满了，但 df -h 和 du -sh 对不上，应该怎么排查？

  • 核心要点

    • 先区分是块空间满还是 inode 满
    • df -h 看文件系统整体使用率，df -i 看 inode
    • du -sh 统计的是当前目录树下“看得见”的文件
    • 若文件被删除但进程未释放句柄，du 看不到，df 仍然显示占用
    • 容器场景要重点看日志、镜像层、挂载卷、已删除文件句柄

  • 易错点

    • 只会看 df -h，不会看 df -i
    • 误删日志却不知道重启/重载进程释放句柄
    • 忽略 /var/lib/containerd、/var/lib/docker、/var/log/pods 等路径

  • 深挖点

    • 排查 deleted file 常用什么命令？——lsof | grep deleted
    • 为什么小文件很多时 inode 会先满？
    • K8s 节点磁盘打满后，可能引发哪些连锁问题？——Pod 驱逐、镜像拉取失败、容器启动失败
Q9：如果磁盘 I/O 很高，如何从操作系统层面定位问题？

  • 核心要点

    • 先看是否是吞吐高、延迟高、队列长中的哪一种
    • 常用命令：
      • iostat -x
      • iotop
      • vmstat
      • pidstat -d
      • sar -d
    • 重点指标：
      • await：平均 I/O 等待时间
      • %util：设备利用率
      • r/s、w/s：每秒读写次数
      • rkB/s、wkB/s：吞吐
    • 结合业务进程、容器日志、存储后端一起看

  • 易错点

    • 只看 %util 就判断磁盘有问题
    • 不区分随机 I/O 和顺序 I/O
    • 不结合应用访问模式，只盯系统命令输出

  • 深挖点

    • await 很高说明什么？
    • SSD 和 HDD 在 I/O 指标判断上有什么不同？
    • 如果是 K8s 环境，怎么定位到具体是哪个 Pod/容器导致 I/O 抖动？
Q10：为什么 etcd、数据库这类组件对存储特别敏感？K8s 运维要注意什么？

  • 核心要点

    • etcd 是 K8s 控制面的核心元数据存储，对延迟和持久化要求高
    • 存储抖动会直接影响 API Server 响应、Leader 选举、集群稳定性
    • etcd 更关注：
      • 低延迟
      • 稳定 fsync
      • 独立磁盘/高性能盘
    • 不建议把 etcd 和高 I/O 业务混跑在同一慢盘上

  • 易错点

    • 只看 CPU 和内存，忽略磁盘延迟
    • 以为“磁盘没满”就说明存储没问题
    • 把 etcd 放到共享、延迟抖动大的存储上

  • 深挖点

    • 为什么 fsync 抖动会影响 etcd 性能？
    • etcd 适合什么类型的磁盘？
    • 如何从监控指标判断 etcd 存储瓶颈？

速记笔记

  • 文件系统链路：进程 -> fd -> file -> dentry -> inode
  • inode 存元数据，不存文件名
  • write 成功 ≠ 真正落盘，真正持久化要看 fsync
  • ext4 稳定通用，xfs 更常见于大盘和容器场景
  • RAID 解决冗余/性能，LVM 解决灵活管理/扩容
  • 容器写数据默认常在可写层，不等于持久化
  • K8s 存储主线：PVC 申请 -> PV 绑定 -> StorageClass/CSI 提供
  • 块存储偏数据库，文件存储偏共享目录，对象存储偏 API 访问
  • df -h 看空间，df -i 看 inode，du 看可见文件占用
  • rm 后空间不回收，先想：进程是否还占着 deleted 文件
  • I/O 排查重点看：await、%util、队列、具体进程/Pod
  • etcd 最怕高延迟、fsync 抖动、慢盘混部