Linux 大文件查找与清理技巧

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 清空内容，保留文件 inode 和权限，多数日志服务（rsyslog、journald）能继续写入
• 确认无进程占用再删：用 lsof +L1 查找已删除但仍被打开的“幽灵文件”，或 lsof 看谁在写
• 对 systemd-journal 日志，用 journalctl --vacuum-size=500M 更稳妥，它会自动轮转并释放空间
• 避免 echo "" > file：某些程序检测到文件 size 变为 0 会异常退出

du 和 df 显示的可用空间差很多，怎么定位“看不见”的大文件？

df 显示已用空间远高于 du -sh * 总和，常见原因是：已删除但未释放的文件（lsof +L1）、挂载覆盖（如 /mnt/disk 下有旧文件被新挂载遮住）、或容器/快照残留数据。

华友协同办公自动化OA系统

华友协同办公管理系统(华友OA)，基于微软最新的.net 2.0平台和SQL Server数据库，集成强大的Ajax技术，采用多层分布式架构，实现统一办公平台，功能强大、价格便宜，是适用于企事业单位的通用型网络协同办公系统。 系统秉承协同办公的思想，集成即时通讯、日记管理、通知管理、邮件管理、新闻、考勤管理、短信管理、个人文件柜、日程安排、工作计划、工作日清、通讯录、公文流转、论坛、在线调查、

下载

• 先运行 lsof +L1，重点看 DEL 状态行，记下 PID 和文件路径，然后 kill -USR1 （对支持该信号的服务）或重启对应服务
• 检查挂载点嵌套：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 恢复（需立即卸载分区并停止写入），但成功率低，不能依赖