判断磁盘空间是否真不足需先查inode、删除未释放文件及挂载遮蔽；LVM扩容后须用resize2fs或xfs_growfs调整文件系统；tmpfs内存占用不显于进程列表，应查cgroup和挂载参数；RAID重建失败应镜像磁盘后手动组装或直接扫描恢复。
如何判断当前磁盘空间是否真的不足
很多用户看到 df -h 显示 / 分区使用率 95% 就立刻紧张，但实际可能只是日志或临时文件占位，而非真实业务数据增长。先确认是不是 inode 耗尽、是否有大文件被删除但句柄未释放、或者挂载点被隐藏覆盖。
- 检查 inode 使用：运行
df -i，若Use%接近 100%，即使空间充裕也会无法创建新文件 - 查找已删除但仍在占用空间的文件：执行
lsof +L1，重点关注deleted状态的REG类型文件 - 排查挂载遮蔽：用
findmnt或mount | grep "on /"确认根目录下是否存在嵌套挂载（如/var/log单独挂载后又被覆盖） - 快速定位大目录：在疑似满载分区运行
du -sh /* 2>/dev/null | sort -hr | head -5
逻辑卷（LVM）扩容时为什么 lvextend 成功但文件系统没变大
LVM 的 lvextend 只负责扩大逻辑卷设备本身，不自动调整上层文件系统。这是最常被忽略的断点，尤其在 XFS 和 ext4 上操作差异明显。
- ext4 必须后续执行
resize2fs /dev/vgname/lvname（在线可做） - XFS 必须用
xfs_growfs /mount/point，且只接受挂载点路径，不能传设备名 - 如果扩容前文件系统已损坏，
resize2fs会报错退出，需先e2fsck -f /dev/vgname/lvname - 不要对未挂载的 XFS 执行
xfs_growfs——它会直接失败并提示not a mounted XFS filesystem
使用 tmpfs 时为何内存占用飙升却查不到对应进程
tmpfs 是基于内存和 swap 的虚拟文件系统，其空间计入 MemAvailable 和 SwapFree 的消耗，但不会出现在 ps 或 top 的进程内存列中。它属于内核直接管理的页缓存范畴。
- 查看实际占用：读取
/sys/fs/cgroup/memory/memory.usage_in_bytes（若启用 cgroup v1）或cat /sys/fs/cgroup/memory.max+usage（v2） - 检查挂载参数：
mount | grep tmpfs，重点看size=和nr_inodes=是否设得过大 - 常见误用：将
/tmp挂为tmpfs size=10G，但应用反复写入小文件又不清理，导致 inode 耗尽或触发 swap 溢出 - 安全做法：为
tmpfs指定mode=1777和uid=0,gid=0，避免非 root 写入失控
RAID 重建失败后还能否抢救部分数据
RAID 5/6 降级状态下仍可读，但一旦开始重建又中断（如掉电、重启），阵列元数据可能处于不一致状态，此时强制启动风险极高。抢救核心是「停止写入 + 逐盘镜像 + 基于副本恢复」。
- 立即卸载所有 RAID 设备：
umount /dev/md0，禁止任何mdadm --assemble自动尝试 - 对每块物理盘做 bit-by-bit 备份：
dd if=/dev/sdX of=/backup/sdX.img bs=4M conv=noerror,sync - 用
mdadm --examine /backup/sdX.img提取各盘的 superblock 信息，比对Event Count找最新的一组 - 手动指定盘序组装（不依赖元数据）：
mdadm --build /dev/md99 --raid-devices=3 --level=5 /backup/sdX.img /backup/sdY.img /backup/sdZ.img - 若仅需关键文件，可跳过组装，直接用
photorec或testdisk在单个.img文件中扫描恢复
真正卡住存储管理的，往往不是命令记不住，而是搞不清哪一层在起作用——是块设备、LVM 元数据、文件系统结构，还是内核内存管理策略。动手前多看一眼 lsblk 和 cat /proc/mounts，比盲目 lvextend 安全得多。
