bind mount 不占磁盘空间但会导致 df 与 du 统计偏差；需用 findmnt -d 和 mount 验证是否被覆盖，再以 du -shx 限制跨文件系统统计，并检查源目录及已删除未释放文件。

Bind Mount 本身不直接占用磁盘空间，但它可能掩盖真实存储位置，导致 df 和 du 统计结果严重偏差，进而误判“磁盘占满”——实际是挂载覆盖了原目录，而空间被算在了错误的文件系统上。

确认目标路径是否被 bind mount 覆盖

这是最常被忽略的第一步。如果 /var/log 被 bind mount 到另一个目录（比如 /data/logs），那么：

• du /var/log 统计的是 /data/logs 下的内容（可能很大）
• df /var/log 显示的是根分区（/dev/vda1）的剩余空间（可能已近 100%）
• 但真正占空间的文件其物理位置其实在 /data/logs 所在的分区（比如 /dev/vdb1）上

执行以下命令验证：

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• findmnt -D /var/log —— 查看完整挂载树，识别是否有 --bind 条目
• mount | grep " /var/log " —— 注意前后空格，精准匹配挂载点
• ls -ld /var/log && ls -l /proc/mounts | grep /var/log —— 检查权限与挂载源一致性

区分统计范围：避免跨文件系统误算

bind mount 后，du /var/log 默认会穿透到被绑定的目标路径，但你真正想排查的是“该挂载点所属的底层文件系统是否真的满了”。这时必须限制统计范围：

• 用 du -shx /var/log（-x 参数表示不跨文件系统）—— 只统计 /var/log 所在分区上的、未被覆盖的残留内容（通常极小）
• 对比 df -h /var/log 输出，若两者差值巨大（如 du 显示 4MB，df 显示已用 45G），基本可断定是 bind mount 导致统计对象错位
• 再运行 df -h $(readlink -f /var/log)，查看被绑定目标的实际空间使用情况

检查被绑定源目录是否异常膨胀

一旦确认存在 bind mount，重点就转向被绑定的源目录（例如 /data/logs）。它很可能才是真正吃掉空间的地方：

• 进入源路径：cd /data/logs
• 快速定位大目录：du -sh * 2>/dev/null | sort -hr | head -n10
• 查找大文件（尤其日志）：find . -type f -size +100M -ls | sort -k7 -hr | head -n10
• 注意：若源目录本身也挂载在其他设备上（如 /data 是独立分区），需再次用 df -h /data 确认其所在设备是否真的快满

警惕“已删除但未释放”的文件干扰

bind mount 不影响内核的文件引用机制。如果被绑定目录中有进程仍在写一个已被 rm 删除的日志文件（如 java 进程持续向 /data/logs/app.log 写入，然后你执行了 rm app.log），该文件的磁盘空间不会释放，du 也统计不到它，但 df 仍计入已用空间。

• 检查方法：lsof +L1 /data/logs（列出所有链接数为 0 的打开文件）
• 或更通用：lsof | grep '/data/logs.*deleted'
• 解决方式：重启对应进程，或用 echo > /proc/PID/fd/FD_NUM 清空句柄（需谨慎）