Linux中删除文件后空间未释放，主因是进程仍占用已删文件句柄；需用lsof +L1定位，再重启进程或平滑重载日志，而非直接kill -9。
文件被进程占用导致空间无法释放
Linux 中删除文件只是移除了目录项（unlink），如果仍有进程打开该文件，其 inode 和数据块仍被保留，磁盘空间不会立即回收。常见于日志文件被服务持续写入的场景，比如 nginx、java 或 dockerd 进程仍在向已删除的 /var/log/app.log 写入。
- 用
lsof +L1查看所有“已删除但仍被打开”的文件（+L1 表示 link count 为 0） - 更精准可查指定挂载点：
lsof +L1 /var - 确认后，重启对应进程（如
systemctl restart nginx）或用kill -USR1触发日志重开（部分服务支持） - 注意：直接
kill -9可能导致数据丢失或服务异常，优先选平滑 reload
/proc/*/fd/ 下的 deleted 文件描述符
即使文件已被 rm，只要进程没关闭 fd，它在 /proc/[pid]/fd/ 下仍以 xxx (deleted) 形式存在。这是内核级引用，不依赖路径，仅靠 fd 维持数据块存活。
- 执行
ls -l /proc/*/fd/ | grep deleted可快速定位可疑进程 - 配合
ps -p [pid] -o pid,comm,args查看进程详情 - 若确认是误占且无业务影响，可用
echo > /proc/[pid]/fd/[fd_num]清空内容（慎用），或终止进程 - 某些容器环境（如 Docker）中，宿主机上看不到容器内进程，需进容器查
lsof或用docker exec -it [cid] lsof +L1
ext4 的延迟分配与 block reservation
ext4 默认启用延迟分配（delayed allocation），新写入可能暂未落盘，而删除操作又释放了旧块，但内核缓存或 journal 尚未提交，导致 df 显示空间未更新。这种情况通常在几秒到一分钟内自动收敛，但高负载或 journal 拥塞时会延长。
- 检查是否卡在 journal 提交：
dmesg | tail -20 | grep -i "journal" - 强制同步缓存：
sync（注意：不能解决进程占用问题，仅刷新脏页） - 禁用延迟分配会影响性能，不建议日常调整；可通过挂载选项
mount -o remount,delalloc=0 /dev/sda1临时验证，但需卸载重挂 -
df和du差异大时，先排除进程占用，再考虑 ext4 行为
容器或 overlayfs 场景下的空间释放延迟
Docker 使用 overlay2 时，删除容器或镜像可能不立即释放底层 /var/lib/docker/overlay2 空间，尤其当有运行中容器共享同一层、或存在 dangling layer 引用时。
- 运行
docker system df -v查看各层实际占用和引用关系 -
docker system prune -a --volumes清理无引用对象（注意：会删掉所有停止容器、未打标签镜像、构建缓存和匿名卷） - 检查是否有僵尸层：
find /var/lib/docker/overlay2 -name "diff" -type d -empty -delete 2>/dev/null（慎用，建议先ls确认） - overlay2 的 lowerdir/upperdir/workdir 结构复杂，直接
rm -rf/var/lib/docker/overlay2/*会导致 docker daemon 崩溃
lsof +L1 应该是第一个敲的命令，而不是最后一个。 
