find按大小查找漏目标因默认单位是512字节块，+100M实为51.2KB；须显式用b/k/M/G单位，且M区分大小写。
find 按大小查找大文件时为什么总漏掉目标？
默认 find 的 -size 参数单位是「512 字节块」，不是 KB 或 MB。写成 find /var -size +100M 看似合理，但实际会被解释为「+100×512 字节」（即 51.2KB），远小于预期。
- 正确写法必须显式加单位：用
b（字节）、k（KiB）、M（MiB）、G（GiB）——例如find /var -size +100M才真指 100 MiB 以上 - 注意大小写：
m不被识别，M才有效；+1G匹配 ≥1 GiB，-1G匹配 - 如果路径含空格或特殊字符，务必用引号包裹，否则 shell 展开可能出错
- 权限不足时
find会报Permission denied，可用2>/dev/null抑制，但别因此忽略真正需要检查的目录
如何安全删除日志类大文件而不中断服务？
直接 rm 正在被进程写入的日志（如 /var/log/syslog）会导致磁盘空间不释放——因为文件句柄仍被持有，只是目录项被删了。真正的释放要等进程重启或主动 reload。
- 优先用
truncate -s 0 <file></file>清空内容，保留文件 inode 和权限，多数日志服务（rsyslog、journald）能继续写入 - 确认无进程占用再删：用
lsof +L1查找已删除但仍被打开的“幽灵文件”，或lsof <file></file>看谁在写 - 对 systemd-journal 日志，用
journalctl --vacuum-size=500M更稳妥，它会自动轮转并释放空间 - 避免
echo "" > file：某些程序检测到文件 size 变为 0 会异常退出
du 和 df 显示的可用空间差很多，怎么定位“看不见”的大文件？
df 显示已用空间远高于 du -sh * 总和，常见原因是：已删除但未释放的文件（lsof +L1）、挂载覆盖（如 /mnt/disk 下有旧文件被新挂载遮住）、或容器/快照残留数据。
- 先运行
lsof +L1，重点看DEL状态行，记下 PID 和文件路径，然后kill -USR1 <pid></pid>（对支持该信号的服务）或重启对应服务 - 检查挂载点嵌套：
mount | grep "on /path"，确认 /path 是否被其他设备覆盖；临时umount /path后再du -sh /path - Docker 用户注意：
docker system df查镜像/容器/卷占用，docker builder prune清构建缓存，docker volume ls -q | xargs docker volume rm清空未使用卷（慎用）
清理时误删系统关键文件怎么办？
Linux 没有回收站机制，rm 是立即不可逆操作。唯一可靠的事前防护是限制权限 + 验证路径。
- 永远不要在 root 下直接
rm -rf /*类命令；用rm -i强制交互确认，或先ls/find ... -print预览匹配结果 - 对批量操作，先用
find ... -exec echo {} \;替代rm，确认输出无误再换rm - 重要服务器建议配置
alias rm='rm -I'（大写 i，对 3 个以上文件才提示），并禁用rm -f别名 - ext4 文件系统可尝试
extundelete恢复（需立即卸载分区并停止写入），但成功率低，不能依赖
rm 前多看一眼 lsof 和 systemctl status，比事后救火省十倍力气。 
