说起来挺有意思做运维或者后端的人十有八九都遇到过这么一幕磁盘告警了你火急火燎地敲下rm -rf /data/log/xxx.log眼看着文件没了心里刚松了一口气再df -h一看——磁盘空间居然一点没变还是红着脸在报警。我当时第一次遇到这情况还以为自己眼花了甚至怀疑是不是命令没生效反复操作了好几次才确认文件确实删了但空间确实也没释放。这个“Linux 文件删除后空间不释放”的问题算是 Linux 系统运维里一个非常经典的“看似简单、实则坑深”的场景。它不像磁盘满了一样报个No space left on device那么直接而是让你在“删了等于没删”的错觉里一头雾水。这篇文章我就把自己这些年排查这类问题的完整思路、原理拆解、实操命令和一些踩过的坑一次性讲清楚。不论你是刚接触 Linux 的运维新人还是被这个问题困扰过的后端开发、嵌入式工程师这篇文章都能帮你把这块知识补上以后再遇到心里就有底了。1. 问题表象与根因剖析为什么文件没了空间却还在1.1 从文件系统结构说起文件名、inode 与数据块的关系要彻底搞明白这个问题得先摒弃一个日常直觉我们平时说的“删文件”在 Linux 里做的事和我们脑子里的想象不太一样。很多人以为删除文件就是把磁盘上那些 0 和 1 的数据抹掉。实际上Linux 文件系统里一个文件由三部分构成目录项dentry、索引节点inode和数据块。目录项记录了文件名和 inode 编号的对应关系inode 里存的是这个文件的元信息——大小、权限、时间戳最关键的是指向数据块的指针以及一个叫“链接计数”i_link 或 nlink的字段。数据块才是真正存放文件内容的地方。当我们执行rm命令时系统做的工作仅仅是把文件名从父目录的目录项里移除同时把 inode 的链接计数减 1。如果这个 inode 的链接计数减到了 0那么系统才会认为这个文件无人使用了真正把 inode 和数据块标记为可分配。注意这里也只是“标记为可分配”并没有立刻去把数据块用 0 覆盖掉但此时对系统来说空间已经算是释放了可以被后续写入使用。有朋友可能已经想到了如果链接计数减到了 0那空间就该释放啊为什么df还显示占用别急关键就在“链接计数为 0”这个条件上。如果一个文件被删除后仍然有一个进程持有它的文件描述符fd那么这个 inode 的链接计数虽然在目录项层面被减到了 0但因为文件还被进程打开着inode 自己还有一个“引用计数”不为 0。这种情况下内核会认为“文件虽然已经被删除了但还有人在用它的数据我不能把数据块收回去。”于是这个 inode 就变成了一个特殊状态——在/proc文件系统里它会被标记为deleted。数据块一直被占用着空间自然就不会释放。只要那个进程不关闭这个文件描述符这块空间就一直是“僵尸空间”看得见摸不着但实实在在占着磁盘。1.2 用“保险柜”类比彻底理解这个机制我在给别人讲这个概念的时候喜欢用一个类比想象你租了一个保险柜里面的文件是你重要的纸质资料。现在你觉得不需要了就在保险柜的登记簿上把这个柜子划掉了表示“这个柜子名义上已经不归我用了”。但问题是保险柜的钥匙还在某个员工手里而且那个员工还在时不时打开柜子翻看文件。那么对于保险柜的管理公司来说这个柜子能被重新租给别人吗当然不能。它虽然被划掉了但内部还是被占用的。Linux 里的情况完全一样rm只是把“登记簿上的名字划掉”删除目录项但进程打开的 fd 就是“钥匙”。只要钥匙还在inode 和它指向的数据块就依然被系统认为是“活跃”的空间也就不可能真正空出来。明白了这个底层机制后面所有排查思路就顺理成章了。2. 定位真凶用 lsof 找出占用文件的“罪魁祸首”2.1 lsof L1一把梭还是分步走既然根因是“有进程占用了已删除文件的 fd”那排查思路就非常清晰了去进程列表里找出谁还拿着这把“钥匙”。Linux 下最常用的命令自然是lsoflist open files。我的习惯是先在出问题的分区根目录跑一条lsof L1看看有哪些文件处于 deleted 状态。这里的L1表示列出打开的文件中链接计数小于 1 的也就是已经被删除但还开着的文件。我曾在生产环境一台日志服务器上执行过这个命令输出大概是这样的COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 2345 root 1w REG 253,1 8589934592 456789 /data/logs/application.log (deleted) java 2345 root 2w REG 253,1 8589934592 456789 /data/logs/application.log (deleted) nginx 1234 root 6u REG 253,1 1234567 345678 /var/log/nginx/access.log (deleted)这里的信息非常关键。COMMAND和PID告诉我们哪个进程在占用FD列里的1w表示文件描述符 1标准输出以写模式打开TYPE是REG普通文件DEVICE是 253:1主设备号:次设备号SIZE/OFF是当前文件偏移量这也就是文件被删之前占据的空间大小。最后一列NAME括号里的deleted就是实锤。拿到这些信息后解决办法通常就是那句老话要么让进程自己把 fd 关掉重启进程要么杀掉进程。比如上面 java 进程重启一下或者优雅停掉再拉起空间就释放了。nginx 的 access.log 被占着句柄对 nginx 执行nginx -s reopen重新打开日志文件也能解决。2.2 没有 lsof 或不想装用 fuser 和 /proc 兜底有些生产环境非常严格不让随便装新软件。或者你用了精简版容器镜像里面压根没有 lsof。这时候别慌Linux 还留了两条路。第一条是用fuser。它能直接告诉你哪个进程正在使用某个文件或目录。比如fuser -v /data/logs/application.log然后fuser -k /data/logs/application.log可以直接杀掉占用进程。但要注意fuser -k有点暴力会直接 SIGKILL 进程建议先加上-v看输出确认之后再用。第二条更底层走/proc文件系统。每个进程都有一个目录/proc/PID/fd/里面是进程打开的所有文件描述符。我们可以用一条命令扫描出被标记为 deleted 的 fdls -l /proc/*/fd/ 2/dev/null | grep deleted输出结果里会看到类似/proc/2345/fd/1 - /data/logs/application.log (deleted)的信息。这种方式比 lsof 更“原生态”尤其在没有安装 lsof 的容器里特别好使。2.3 无论哪种方式搞清楚“要杀还是要留”这里我得提醒一句找到占用进程之后不要条件反射地抡起kill -9就上。如果这个进程是核心业务比如数据库、网关直接杀掉可能造成更严重的服务中断。我自己遇到过不止一次磁盘空间看着马上要满但占用这个文件的应用在跑一个重要任务根本没有窗口重启。正确姿势是先评估占用进程是什么能不能重启重启会不会丢状态如果业务允许优雅重启是第一选择如果业务不允许可以看看是否是日志类文件、临时文件被占用有些程序支持通过信号量重新打开日志句柄比如向进程发送SIGHUP或者用 nginx 的reopen机制让程序自己把新日志写到新文件里旧的 deleted inode 就会在内部释放。实在不行再考虑 kill。不要因为急于释放磁盘而把整个应用搞挂了那就得不偿失了。3. 日志文件场景别再用 rm 了清空才是正确姿势3.1 rm 日志后程序继续写的“假释放”陷阱这是个让我吃过亏的典型场景。以前一台业务服务器的日志文件特别大我嫌它占空间直接rm -rf /var/log/myapp/current.log操作了一波。结果 df 一看空间纹丝不动。一查 lsof发现程序还开着这个文件写日志。更尴尬的是因为文件已经被删除了程序往这个 fd 里写的数据是“写入空气”你再也找不到这些日志了但磁盘空间却被这些“空气数据”一直占着。这种场景下如果我无限期不处理程序就会一直写一个看不见的日志文件直到把磁盘空间完全吃满。此时你连排查问题的日志都看不见只能干瞪眼。3.2 truncate 与 file 的正确用法所以对于日志文件这类“程序会持续写入”的文件正确的做法不是rm而是“清空内容”。清空内容的命令主要有这么几种truncate -s 0 /var/log/myapp/current.log或者: /var/log/myapp/current.log也可以cat /dev/null /var/log/myapp/current.log这几个命令的本质都是把文件的内容截断为 0 字节但文件本身、inode、fd 都还在原地。对于持有 fd 的进程来说它的写偏移量还在某个位置但由于文件大小变成了 0后续写入的数据会重新从偏移量开始写像是“重新从空文件的开头继续追加”。这样既释放了磁盘空间又不影响进程继续写日志还保留了日志文件的可读性。我在后面慢慢意识到生产环境里其实应该把这个习惯固化下来清理日志首选 truncate 而不是 rm。除非某个日志文件已经确认不再需要、程序也不再打开它了才用 rm。而且最好配合 logrotate 使用让日志自动切割、自动清空那才是治本之策。3.3 定时清理 Web/应用日志的实操模板如果你已经被日志撑爆磁盘的问题折磨过可以考虑在 crontab 里加一个定时任务。我分享一个自己在用的模板30 23 * * * /usr/bin/find /var/log/nginx -type f -name *.log -mtime 7 -size 100M -exec truncate -s 0 {} \;这条 crontab 的意思是每天晚上 11 点半找出/var/log/nginx目录下 7 天前创建、且当前大小超过 100MB 的日志文件对它们执行清空操作。用truncate而不是rm就是为了避免 nginx 还在写日志时文件被删造成空间不释放的问题。如果你用的是系统自带的 logrotate也可以看看它的配置里是否有copytruncate这个选项这个是专门为了在程序仍持有旧文件句柄时也能正确轮转日志用的。它先复制当前日志内容备份然后清空原文件非常实用。4. 其他经典场景硬链接残留与隐藏的“空间黑洞”4.1 rm 掉一个硬链接数据却还在除了进程占用 fd另一个常见原因是硬链接。有些系统里为了管理方便同一个文件会有多个硬链接比如备份脚本、快照机制都可能在两个不同目录下创建指向同一个 inode 的硬链接。当你rm掉其中某一个文件名时inode 的链接计数只是从 2 减到 1并没有变成 0所以数据块依然被系统视为“还有人在用”空间自然不释放。这时候哪怕你用 lsof 查也可能一无所获因为没有进程打开它纯粹是“另一个文件名”把这个 inode 续命了。排查方式很简单用find -inum按 inode 号全局找一遍find / -type f -inum 456789 2/dev/null如果找到另外的路径指向这个 inode那么把那个路径也删掉或者在确认无用后清空空间才能真正释放。平时判断文件有没有硬链接可以用stat file看输出的Links:字段值大于 1 就说明有多个名字指向同一份数据。4.2 挂载点目录、NFS/网络共享与“删不掉的进程”还有一种很低调的情况有进程的工作目录cwd在某个挂载点里但目录的引用关系比较复杂。比如某个进程一开始cd到了/home/user/abc之后 abc 目录被重命名或删除了但进程还在那个目录下运行这也会导致 umount 时提示target is busy或者挂载点目录本身无法释放。排查这种问题用的是lsof D /path或者先fuser -m /mount/point看哪些进程使用着这个挂载点。尤其是在 NFS、CIFS/Samba 共享目录里删除大文件时如果客户端和服务端任意一边还有进程持有 fd文件在服务器端可能一直显示为被占用。我遇到过在挂载的 NAS 共享目录里删除一个超大文件客户端这边看空间没释放最后lsof查到是本地一个同步进程一直握着这个 fd 不放。处理办法要么等同步进程超时要么 kill 后重新挂载。4.3 警惕“回收站机制”带来的删不掉假象这里要岔开提一句因为有时候 Linux 下删除“失败”不只是空间不释放还可能是文件根本删不掉。比如某些国产 Linux 桌面环境像麒麟、统信自带桌面回收站机制你在图形界面下删除文件其实是移动到回收站目录并不是真正删除。如果回收站目录创建失败或者权限不对就会弹出“无法为找到或创建回收站目录”之类的提示。这时的解决路径不是让空间释放而是去检查回收站目录是否存在通常位于~/.local/share/Trash/或者/data/.Trash-UID/这种隐藏路径手动确认下权限即可。这类问题虽然和“空间不释放”严格来说不太一样但现象上有相似之处很多时候让人误判成同一个问题。4.4 页缓存Page Cache的干扰再补充一个容易被误认为“空间不释放”的情况df里看到的 used 空间和你在du里把所有目录加起来算出的总量对不上。这不一定是有隐藏文件还有可能是页缓存导致的统计差异。不过要注意页缓存本身是被内核管理的它会随着内存压力自动回收并不会真正被视为“不可释放”。但如果你的内存疯狂吃紧又没有释放动作sync之后页缓存会写入磁盘写入的数据可能临时反映在 used 空间上。一般我们不把这种情况列为“删除后空间不释放”的元凶但它确实是排查异常磁盘占用时需要排除的一个因素。当你想深入审计每个目录占用了多少空间时记得用du -x --max-depth1 -h /data这样限制在同一文件系统内统计。5. 常见问题速查与排查思路手册5.1 一条龙排查命令对照表平时排查这类问题我会按下面的顺序玩一遍大家可以直接抄作业目的命令注意事项看整体磁盘占用df -h确认是哪个分区出了问题关注 Use%确认是 inode 耗尽还是块耗尽df -i如果 inode 满了即便有空间也创建不了文件找出 deleted 状态打开文件lsof L1没有 lsof 的用ls -l /proc/*/fd/ 2/dev/null | grep deleted查看特定文件被谁占用fuser -v /path/to/file也可以lsof /path/to/file按 inode 查找路径find / -inum 456789 2/dev/null用于排查硬链接未释放检查文件详细状态含链接数stat /path/to/file观察Links字段和Size字段查看进程工作目录ls -l /proc/PID/cwd排查进程停留在删除目录里的情况5.2 实战问答这些现象我该怎么处理Q1我用rm -rf删了一个 50GB 的文件df显示磁盘还是满的lsof 什么都没输出怎么办 A1lsof 什么都没输出不代表没有进程占用可能是当前用户权限不够看不到别的进程的 fd。先sudo lsof L1再试一次。如果依然没有考虑硬链接用find / -inum inode号全局找一下。还有可能你删除的是稀疏文件或文件本身在奇怪的文件系统上比如某些虚拟磁盘的 overlay 层那种情况需要特殊处理。Q2删文件时一直显示“0%”的进度条比如用某些图形工具或者在 Windows 的共享文件夹里删除一直卡住这怎么办 A2如果是 Windows 访问 Linux 共享目录时删除文件一直卡住多半是 Samba 服务端有进程占用了文件Windows 客户端在等待锁释放。可以在服务端执行lsof \| grep deleted或smbstatus看看谁的会话占用了。如果是纯 Linux 图形环境下卡住多半是回收站或索引服务的问题检查回收站目录权限、关闭文件索引服务试试。Q3我清空了日志文件之后空间确实释放了但下次日志一写又开始增长有什么一劳永逸的办法吗 A3一劳永逸必须上 logrotate。在/etc/logrotate.d/下写一个配置指定日志文件路径、切割周期daily/weekly、保留份数rotate 7、是否压缩compress还要根据程序是否会一直持有句柄来决定是否加copytruncate。例如/var/log/myapp/*.log { daily rotate 15 compress copytruncate missingok notifempty }copytruncate是应对持有旧句柄进程的关键选项——它先复制内容到新文件再把原文件截断为 0程序继续写旧 fd 也不影响。Q4CentOS 和 Ubuntu 上遇到这类问题处理方式有区别吗 A4核心机制完全一样只是命令工具的默认安装情况有差异。CentOS/RHEL 系一般预装 lsofUbuntu/Debian 系有时需要apt install lsof。别的命令如stat、find、fuser都是基础工具缺什么装什么即可。Q5生产环境磁盘 wrote full没有空间执行任何写入重启进程又怕出问题还有什么变通方法 A5这种情况先拆东墙补西墙——去/tmp或者其他临时目录删掉无关紧要的文件腾出一点点空间让系统有能力执行必要的操作另一个办法是找到占用空间最大的 deleted inodelsof L1里SIZE/OFF最大的那个如果进程是可重启的做一次优雅重启释放空间。千万注意不要在磁盘满时贸然重启 MySQL、PostgreSQL 这类强一致性数据库如果崩溃恢复需要额外空间反而会起不来。真遇到这种极端情况先和业务方对时间窗口再动手。5.3 日常习惯上的三个建议最后说几个我踩过坑后的心得体会。第一不要养成“看到大文件就 rm”的习惯尤其对日志类和应用运行时文件优先清空或 truncate。第二对重要目录的删除操作养成df -h和df -i前后对比的习惯有疑问立马上 lsof。第三告警监控里不要只盯磁盘空间把 inode 使用率也盯起来inode 满了同样会导致文件删除异常、空间诡异地不释放。特别是那些每天产生大量小文件的应用比如消息队列的临时分片、Python 的__pycache__、Java 的临时文件inode 耗尽速度远超你的想象。这种问题本质上是 Linux 文件系统“延迟释放”的一种体现理解它之后再看各种磁盘“假满”现象思路就会清晰很多。排查命令就那么几条原理也就那么一层窗户纸捅破之后以后任何同事再喊你“磁盘删了文件但空间没释放”你就能胸有成竹地拍着胸脯说来先跑一下 lsof。
Linux文件删除后空间不释放？原理与排查命令全解析
说起来挺有意思做运维或者后端的人十有八九都遇到过这么一幕磁盘告警了你火急火燎地敲下rm -rf /data/log/xxx.log眼看着文件没了心里刚松了一口气再df -h一看——磁盘空间居然一点没变还是红着脸在报警。我当时第一次遇到这情况还以为自己眼花了甚至怀疑是不是命令没生效反复操作了好几次才确认文件确实删了但空间确实也没释放。这个“Linux 文件删除后空间不释放”的问题算是 Linux 系统运维里一个非常经典的“看似简单、实则坑深”的场景。它不像磁盘满了一样报个No space left on device那么直接而是让你在“删了等于没删”的错觉里一头雾水。这篇文章我就把自己这些年排查这类问题的完整思路、原理拆解、实操命令和一些踩过的坑一次性讲清楚。不论你是刚接触 Linux 的运维新人还是被这个问题困扰过的后端开发、嵌入式工程师这篇文章都能帮你把这块知识补上以后再遇到心里就有底了。1. 问题表象与根因剖析为什么文件没了空间却还在1.1 从文件系统结构说起文件名、inode 与数据块的关系要彻底搞明白这个问题得先摒弃一个日常直觉我们平时说的“删文件”在 Linux 里做的事和我们脑子里的想象不太一样。很多人以为删除文件就是把磁盘上那些 0 和 1 的数据抹掉。实际上Linux 文件系统里一个文件由三部分构成目录项dentry、索引节点inode和数据块。目录项记录了文件名和 inode 编号的对应关系inode 里存的是这个文件的元信息——大小、权限、时间戳最关键的是指向数据块的指针以及一个叫“链接计数”i_link 或 nlink的字段。数据块才是真正存放文件内容的地方。当我们执行rm命令时系统做的工作仅仅是把文件名从父目录的目录项里移除同时把 inode 的链接计数减 1。如果这个 inode 的链接计数减到了 0那么系统才会认为这个文件无人使用了真正把 inode 和数据块标记为可分配。注意这里也只是“标记为可分配”并没有立刻去把数据块用 0 覆盖掉但此时对系统来说空间已经算是释放了可以被后续写入使用。有朋友可能已经想到了如果链接计数减到了 0那空间就该释放啊为什么df还显示占用别急关键就在“链接计数为 0”这个条件上。如果一个文件被删除后仍然有一个进程持有它的文件描述符fd那么这个 inode 的链接计数虽然在目录项层面被减到了 0但因为文件还被进程打开着inode 自己还有一个“引用计数”不为 0。这种情况下内核会认为“文件虽然已经被删除了但还有人在用它的数据我不能把数据块收回去。”于是这个 inode 就变成了一个特殊状态——在/proc文件系统里它会被标记为deleted。数据块一直被占用着空间自然就不会释放。只要那个进程不关闭这个文件描述符这块空间就一直是“僵尸空间”看得见摸不着但实实在在占着磁盘。1.2 用“保险柜”类比彻底理解这个机制我在给别人讲这个概念的时候喜欢用一个类比想象你租了一个保险柜里面的文件是你重要的纸质资料。现在你觉得不需要了就在保险柜的登记簿上把这个柜子划掉了表示“这个柜子名义上已经不归我用了”。但问题是保险柜的钥匙还在某个员工手里而且那个员工还在时不时打开柜子翻看文件。那么对于保险柜的管理公司来说这个柜子能被重新租给别人吗当然不能。它虽然被划掉了但内部还是被占用的。Linux 里的情况完全一样rm只是把“登记簿上的名字划掉”删除目录项但进程打开的 fd 就是“钥匙”。只要钥匙还在inode 和它指向的数据块就依然被系统认为是“活跃”的空间也就不可能真正空出来。明白了这个底层机制后面所有排查思路就顺理成章了。2. 定位真凶用 lsof 找出占用文件的“罪魁祸首”2.1 lsof L1一把梭还是分步走既然根因是“有进程占用了已删除文件的 fd”那排查思路就非常清晰了去进程列表里找出谁还拿着这把“钥匙”。Linux 下最常用的命令自然是lsoflist open files。我的习惯是先在出问题的分区根目录跑一条lsof L1看看有哪些文件处于 deleted 状态。这里的L1表示列出打开的文件中链接计数小于 1 的也就是已经被删除但还开着的文件。我曾在生产环境一台日志服务器上执行过这个命令输出大概是这样的COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 2345 root 1w REG 253,1 8589934592 456789 /data/logs/application.log (deleted) java 2345 root 2w REG 253,1 8589934592 456789 /data/logs/application.log (deleted) nginx 1234 root 6u REG 253,1 1234567 345678 /var/log/nginx/access.log (deleted)这里的信息非常关键。COMMAND和PID告诉我们哪个进程在占用FD列里的1w表示文件描述符 1标准输出以写模式打开TYPE是REG普通文件DEVICE是 253:1主设备号:次设备号SIZE/OFF是当前文件偏移量这也就是文件被删之前占据的空间大小。最后一列NAME括号里的deleted就是实锤。拿到这些信息后解决办法通常就是那句老话要么让进程自己把 fd 关掉重启进程要么杀掉进程。比如上面 java 进程重启一下或者优雅停掉再拉起空间就释放了。nginx 的 access.log 被占着句柄对 nginx 执行nginx -s reopen重新打开日志文件也能解决。2.2 没有 lsof 或不想装用 fuser 和 /proc 兜底有些生产环境非常严格不让随便装新软件。或者你用了精简版容器镜像里面压根没有 lsof。这时候别慌Linux 还留了两条路。第一条是用fuser。它能直接告诉你哪个进程正在使用某个文件或目录。比如fuser -v /data/logs/application.log然后fuser -k /data/logs/application.log可以直接杀掉占用进程。但要注意fuser -k有点暴力会直接 SIGKILL 进程建议先加上-v看输出确认之后再用。第二条更底层走/proc文件系统。每个进程都有一个目录/proc/PID/fd/里面是进程打开的所有文件描述符。我们可以用一条命令扫描出被标记为 deleted 的 fdls -l /proc/*/fd/ 2/dev/null | grep deleted输出结果里会看到类似/proc/2345/fd/1 - /data/logs/application.log (deleted)的信息。这种方式比 lsof 更“原生态”尤其在没有安装 lsof 的容器里特别好使。2.3 无论哪种方式搞清楚“要杀还是要留”这里我得提醒一句找到占用进程之后不要条件反射地抡起kill -9就上。如果这个进程是核心业务比如数据库、网关直接杀掉可能造成更严重的服务中断。我自己遇到过不止一次磁盘空间看着马上要满但占用这个文件的应用在跑一个重要任务根本没有窗口重启。正确姿势是先评估占用进程是什么能不能重启重启会不会丢状态如果业务允许优雅重启是第一选择如果业务不允许可以看看是否是日志类文件、临时文件被占用有些程序支持通过信号量重新打开日志句柄比如向进程发送SIGHUP或者用 nginx 的reopen机制让程序自己把新日志写到新文件里旧的 deleted inode 就会在内部释放。实在不行再考虑 kill。不要因为急于释放磁盘而把整个应用搞挂了那就得不偿失了。3. 日志文件场景别再用 rm 了清空才是正确姿势3.1 rm 日志后程序继续写的“假释放”陷阱这是个让我吃过亏的典型场景。以前一台业务服务器的日志文件特别大我嫌它占空间直接rm -rf /var/log/myapp/current.log操作了一波。结果 df 一看空间纹丝不动。一查 lsof发现程序还开着这个文件写日志。更尴尬的是因为文件已经被删除了程序往这个 fd 里写的数据是“写入空气”你再也找不到这些日志了但磁盘空间却被这些“空气数据”一直占着。这种场景下如果我无限期不处理程序就会一直写一个看不见的日志文件直到把磁盘空间完全吃满。此时你连排查问题的日志都看不见只能干瞪眼。3.2 truncate 与 file 的正确用法所以对于日志文件这类“程序会持续写入”的文件正确的做法不是rm而是“清空内容”。清空内容的命令主要有这么几种truncate -s 0 /var/log/myapp/current.log或者: /var/log/myapp/current.log也可以cat /dev/null /var/log/myapp/current.log这几个命令的本质都是把文件的内容截断为 0 字节但文件本身、inode、fd 都还在原地。对于持有 fd 的进程来说它的写偏移量还在某个位置但由于文件大小变成了 0后续写入的数据会重新从偏移量开始写像是“重新从空文件的开头继续追加”。这样既释放了磁盘空间又不影响进程继续写日志还保留了日志文件的可读性。我在后面慢慢意识到生产环境里其实应该把这个习惯固化下来清理日志首选 truncate 而不是 rm。除非某个日志文件已经确认不再需要、程序也不再打开它了才用 rm。而且最好配合 logrotate 使用让日志自动切割、自动清空那才是治本之策。3.3 定时清理 Web/应用日志的实操模板如果你已经被日志撑爆磁盘的问题折磨过可以考虑在 crontab 里加一个定时任务。我分享一个自己在用的模板30 23 * * * /usr/bin/find /var/log/nginx -type f -name *.log -mtime 7 -size 100M -exec truncate -s 0 {} \;这条 crontab 的意思是每天晚上 11 点半找出/var/log/nginx目录下 7 天前创建、且当前大小超过 100MB 的日志文件对它们执行清空操作。用truncate而不是rm就是为了避免 nginx 还在写日志时文件被删造成空间不释放的问题。如果你用的是系统自带的 logrotate也可以看看它的配置里是否有copytruncate这个选项这个是专门为了在程序仍持有旧文件句柄时也能正确轮转日志用的。它先复制当前日志内容备份然后清空原文件非常实用。4. 其他经典场景硬链接残留与隐藏的“空间黑洞”4.1 rm 掉一个硬链接数据却还在除了进程占用 fd另一个常见原因是硬链接。有些系统里为了管理方便同一个文件会有多个硬链接比如备份脚本、快照机制都可能在两个不同目录下创建指向同一个 inode 的硬链接。当你rm掉其中某一个文件名时inode 的链接计数只是从 2 减到 1并没有变成 0所以数据块依然被系统视为“还有人在用”空间自然不释放。这时候哪怕你用 lsof 查也可能一无所获因为没有进程打开它纯粹是“另一个文件名”把这个 inode 续命了。排查方式很简单用find -inum按 inode 号全局找一遍find / -type f -inum 456789 2/dev/null如果找到另外的路径指向这个 inode那么把那个路径也删掉或者在确认无用后清空空间才能真正释放。平时判断文件有没有硬链接可以用stat file看输出的Links:字段值大于 1 就说明有多个名字指向同一份数据。4.2 挂载点目录、NFS/网络共享与“删不掉的进程”还有一种很低调的情况有进程的工作目录cwd在某个挂载点里但目录的引用关系比较复杂。比如某个进程一开始cd到了/home/user/abc之后 abc 目录被重命名或删除了但进程还在那个目录下运行这也会导致 umount 时提示target is busy或者挂载点目录本身无法释放。排查这种问题用的是lsof D /path或者先fuser -m /mount/point看哪些进程使用着这个挂载点。尤其是在 NFS、CIFS/Samba 共享目录里删除大文件时如果客户端和服务端任意一边还有进程持有 fd文件在服务器端可能一直显示为被占用。我遇到过在挂载的 NAS 共享目录里删除一个超大文件客户端这边看空间没释放最后lsof查到是本地一个同步进程一直握着这个 fd 不放。处理办法要么等同步进程超时要么 kill 后重新挂载。4.3 警惕“回收站机制”带来的删不掉假象这里要岔开提一句因为有时候 Linux 下删除“失败”不只是空间不释放还可能是文件根本删不掉。比如某些国产 Linux 桌面环境像麒麟、统信自带桌面回收站机制你在图形界面下删除文件其实是移动到回收站目录并不是真正删除。如果回收站目录创建失败或者权限不对就会弹出“无法为找到或创建回收站目录”之类的提示。这时的解决路径不是让空间释放而是去检查回收站目录是否存在通常位于~/.local/share/Trash/或者/data/.Trash-UID/这种隐藏路径手动确认下权限即可。这类问题虽然和“空间不释放”严格来说不太一样但现象上有相似之处很多时候让人误判成同一个问题。4.4 页缓存Page Cache的干扰再补充一个容易被误认为“空间不释放”的情况df里看到的 used 空间和你在du里把所有目录加起来算出的总量对不上。这不一定是有隐藏文件还有可能是页缓存导致的统计差异。不过要注意页缓存本身是被内核管理的它会随着内存压力自动回收并不会真正被视为“不可释放”。但如果你的内存疯狂吃紧又没有释放动作sync之后页缓存会写入磁盘写入的数据可能临时反映在 used 空间上。一般我们不把这种情况列为“删除后空间不释放”的元凶但它确实是排查异常磁盘占用时需要排除的一个因素。当你想深入审计每个目录占用了多少空间时记得用du -x --max-depth1 -h /data这样限制在同一文件系统内统计。5. 常见问题速查与排查思路手册5.1 一条龙排查命令对照表平时排查这类问题我会按下面的顺序玩一遍大家可以直接抄作业目的命令注意事项看整体磁盘占用df -h确认是哪个分区出了问题关注 Use%确认是 inode 耗尽还是块耗尽df -i如果 inode 满了即便有空间也创建不了文件找出 deleted 状态打开文件lsof L1没有 lsof 的用ls -l /proc/*/fd/ 2/dev/null | grep deleted查看特定文件被谁占用fuser -v /path/to/file也可以lsof /path/to/file按 inode 查找路径find / -inum 456789 2/dev/null用于排查硬链接未释放检查文件详细状态含链接数stat /path/to/file观察Links字段和Size字段查看进程工作目录ls -l /proc/PID/cwd排查进程停留在删除目录里的情况5.2 实战问答这些现象我该怎么处理Q1我用rm -rf删了一个 50GB 的文件df显示磁盘还是满的lsof 什么都没输出怎么办 A1lsof 什么都没输出不代表没有进程占用可能是当前用户权限不够看不到别的进程的 fd。先sudo lsof L1再试一次。如果依然没有考虑硬链接用find / -inum inode号全局找一下。还有可能你删除的是稀疏文件或文件本身在奇怪的文件系统上比如某些虚拟磁盘的 overlay 层那种情况需要特殊处理。Q2删文件时一直显示“0%”的进度条比如用某些图形工具或者在 Windows 的共享文件夹里删除一直卡住这怎么办 A2如果是 Windows 访问 Linux 共享目录时删除文件一直卡住多半是 Samba 服务端有进程占用了文件Windows 客户端在等待锁释放。可以在服务端执行lsof \| grep deleted或smbstatus看看谁的会话占用了。如果是纯 Linux 图形环境下卡住多半是回收站或索引服务的问题检查回收站目录权限、关闭文件索引服务试试。Q3我清空了日志文件之后空间确实释放了但下次日志一写又开始增长有什么一劳永逸的办法吗 A3一劳永逸必须上 logrotate。在/etc/logrotate.d/下写一个配置指定日志文件路径、切割周期daily/weekly、保留份数rotate 7、是否压缩compress还要根据程序是否会一直持有句柄来决定是否加copytruncate。例如/var/log/myapp/*.log { daily rotate 15 compress copytruncate missingok notifempty }copytruncate是应对持有旧句柄进程的关键选项——它先复制内容到新文件再把原文件截断为 0程序继续写旧 fd 也不影响。Q4CentOS 和 Ubuntu 上遇到这类问题处理方式有区别吗 A4核心机制完全一样只是命令工具的默认安装情况有差异。CentOS/RHEL 系一般预装 lsofUbuntu/Debian 系有时需要apt install lsof。别的命令如stat、find、fuser都是基础工具缺什么装什么即可。Q5生产环境磁盘 wrote full没有空间执行任何写入重启进程又怕出问题还有什么变通方法 A5这种情况先拆东墙补西墙——去/tmp或者其他临时目录删掉无关紧要的文件腾出一点点空间让系统有能力执行必要的操作另一个办法是找到占用空间最大的 deleted inodelsof L1里SIZE/OFF最大的那个如果进程是可重启的做一次优雅重启释放空间。千万注意不要在磁盘满时贸然重启 MySQL、PostgreSQL 这类强一致性数据库如果崩溃恢复需要额外空间反而会起不来。真遇到这种极端情况先和业务方对时间窗口再动手。5.3 日常习惯上的三个建议最后说几个我踩过坑后的心得体会。第一不要养成“看到大文件就 rm”的习惯尤其对日志类和应用运行时文件优先清空或 truncate。第二对重要目录的删除操作养成df -h和df -i前后对比的习惯有疑问立马上 lsof。第三告警监控里不要只盯磁盘空间把 inode 使用率也盯起来inode 满了同样会导致文件删除异常、空间诡异地不释放。特别是那些每天产生大量小文件的应用比如消息队列的临时分片、Python 的__pycache__、Java 的临时文件inode 耗尽速度远超你的想象。这种问题本质上是 Linux 文件系统“延迟释放”的一种体现理解它之后再看各种磁盘“假满”现象思路就会清晰很多。排查命令就那么几条原理也就那么一层窗户纸捅破之后以后任何同事再喊你“磁盘删了文件但空间没释放”你就能胸有成竹地拍着胸脯说来先跑一下 lsof。