磁盘满了怎么办一次No space left on device报错的完整复盘遇到Could not install packages due to an EnvironmentError: [Errno 28] No space left on device这个报错时第一反应通常是磁盘满了清理一下就完事。但实际处理过几次后发现这个问题远没有表面看起来那么简单——它可能是磁盘真的满了、可能是某个分区满了、可能是inode耗尽、甚至可能是临时目录挂载在内存盘上导致容量受限。我踩过几次坑之后把整个排查和解决过程完整梳理了一遍希望能帮你在下次遇到这个报错时少走弯路。先说说这个报错的典型场景正准备pip install一个包结果终端里直接抛出了上面这行红字安装过程瞬间中断。如果你用conda或者mamba也会遇到类似的提示。报错信息本身已经明确告诉你是设备上没有剩余空间但这只是表象真正要搞清楚的是哪里满了以及为什么满。这篇文章适合谁看刚入门的开发者也好有几年经验的运维和数据处理人员也好只要你的工作环境里需要装Python包、跑机器学习训练或者构建项目依赖这篇内容都能给你一个完整的排查思路。我不仅会讲排查步骤还会把我在实践中遇到的各种边缘情况和对应解法一并分享出来。1. 为什么一个小小的安装动作会碰上磁盘空间问题1.1 问题表象不是所有空间不足都是同一个原因许多人在第一次遇到[Errno 28]时会习惯性地执行df -h查看一下磁盘使用率。如果发现根分区确实满了那自然是清理。但问题是在某些情况下磁盘明明显示还有几十G的空余安装依然报错——这时候就要往更深层次的方向去查了。我自己的经历里有一个非常典型的案例某次我在一台云服务器上给Python环境装运算库磁盘使用率只有40%但安装始终失败报的错就是这个。折腾了半天最后发现是因为/tmp目录被单独挂载而且挂载的是一个只有1G的小分区。pip在解压和编译包的过程中会把临时文件写到/tmp小分区迅速被占满于是安装就中断了。这个案例给我最大的启发是处理这类问题第一步不是急着清理文件而是要先把磁盘的整体布局看清楚。另一个容易被忽略的情况是inode耗尽。如果磁盘上存在大量的小文件比如某些项目里的缓存文件、日志碎片inode会被消耗完。inode是文件系统用来记录文件元信息的存储结构可以理解为文件的索引号。当inode耗尽时即使磁盘还有空闲容量系统也没有办法再创建新文件和目录了。这种场景下df -h显示的空间是充裕的但df -i会告诉你inode使用率已经100%。1.2 安装过程中空间消耗的流转路径要彻底理解这个报错就得清楚安装包时数据是怎么流动的。以pip为例整个安装过程大致是先下载源包或者二进制包到缓存目录然后解压到临时目录接着执行编译或构建流程如果是在本机构建最后再复制到site-packages目录。这个流程里的每一站都涉及磁盘写入缓存目录默认在用户目录下的.cache/pip Windows 下是C:\\Users\\xxx\\AppData\\Local\\pip\\Cache Linux 下是~/.cache/pip。如果你用conda那对应的就是pkgs目录。临时目录主要是/tmp有些系统上由TMPDIR环境变量指定。pip下载完包之后会在这里解压编译过程也会产生中间文件。目标目录也就是site-packages或conda的envs目录。大包比如PyTorch这种几个G的安装包复制进去会需要较大空间。所以排查时不能只盯着一处得把这几条路径的空间都看一下。2. 系统排查从准确诊断到定位占用源头2.1 完整排查命令清单与解读排查思路要按由宏到微的顺序推进我这里列一套我实际常用的命令组合df -h这条命令查看文件系统总容量、已用容量、可用容量、挂载点。重点要确认的是报错进程的工作目录所在分区使用了多少同时观察是否存在多个挂载点各自为政的情况。比如根目录挂在/上而/tmp或/home可能单独挂在另外的设备上。接着看inode情况df -idf -i与df -h的输出结构类似只是把空间换成了inode的用量。这一步是为了确认是否存在文件数爆了但空间没爆的异常情况。查完总量之后要找具体的占用大头。先用下面这条命令看当前目录下的空间占用du -sh * | sort -rh | head -20du -sh *把当前目录下每个子目录/文件的大小汇总成人类可读的格式再经过sort -rh按大小倒序排列head -20取出最大的前20个。这是找出目录里大户最直接的方式。如果想看全盘的目录大小分布比如根目录下哪些一级目录占用了空间可以这样du -x -h --max-depth1 / 2/dev/null | sort -rh | head -30-x参数表示不跨越文件系统边界也就是说只统计根分区本身不会跑到其他挂载点里去。这个参数在排查跨分区问题时特别好用。对于容器场景还要额外检查overlay2目录docker system df如果容器运行时产生了大量镜像、容器层、卷、build cache用这条命令能一目了然地看到空间消耗分布。2.2 存活进程占用与隐藏目录的检查有时候空间确实被某个被删除了但还被进程占用的文件耗着。这种情况常见于日志文件你删了一个正在被服务写入的大日志文件但服务进程还持有该文件的文件描述符空间并不会真正释放。找这类进程可以用lsof L1这个命令可以列出已被删除但仍被打开的文件。L1参数的含义是只显示link count小于1的文件——也就是说文件已从目录结构中移除但仍有进程在使用。如果发现大量空间被这类文件占用重启对应的进程或者把进程kill掉空间就释放了。另外别忘了检查用户目录下的隐藏目录。Python开发者的用户目录下.cache这个目录常常会被忽视。在设备上跑东西跑得久了.cache里可能存了远超预期的数据。处理方式在后面第3节会详细展开。2.3 空间已够但装不上inode和挂载边界问题先看inode的情况。你可以在项目目录里快速创建一个测试文件验证touch testfile如果提示No space left on device而df -h显示有空间那基本可以判定是inode耗尽。解决方式也直接找出大量小文件所在位置并清理。至于挂载边界的问题这里要特别提醒一下用df -h时要留意Filesystem这列如果根目录和/tmp对应的Filesystem不一样说明/tmp是独立的挂载点。独立挂载的/tmp分区如果容量很小就需要重点检查它的占用。有些系统在云平台上默认只给/tmp分配很小的空间而pip的构建流程恰恰重度依赖这个目录。3. 快速回收空间一套顺手可用的清理手段3.1 pip和conda的缓存清理但别一刀切清理pip缓存是最直接的一个方向命令很简单pip cache purgepip cache purge会清空所有pip缓存轮子文件。这个操作本身是安全的只是清掉后下次安装相同的包需要重新下载而已。如果系统中存在多个Python环境或者你是用pip --user方式装的包缓存位置可能在各个用户目录下都需要分别清理。conda的清理命令略有不同conda clean --allconda clean --all会清掉索引缓存、锁文件、未使用的包压缩包和临时文件。和pip的purge一样清理后不会影响已安装环境的功能。需要注意的一点是conda在安装新包时会用pkgs目录里的缓存来加速环境创建清掉缓存之后新建环境时的速度会变慢但不会出错。还有一个细节不要在这种时期急着升级一个大版本的环境。如果conda环境里的包版本和当前Python版本不太匹配conda会尝试重新解压多个包来构建新环境这个过程的临时文件体积可能是环境本身的好几倍。空间紧张时做这种操作极容易再次撞上同一个报错。3.2 临时文件目录的定向清理清理/tmp目录要用一种聪明的方式。直接rm -rf /tmp/*在某些场景下会有风险因为可能有其他正在运行的程序正在使用/tmp里的文件。更稳妥的做法是只清理超过一定时间的临时文件find /tmp -type f -atime 3 -delete find /tmp -type d -empty -delete第一条命令找到/tmp下最后访问时间在3天前的文件并删除第二条清理空目录。这个做法兼顾了安全性和效果——正在使用的文件通常访问时间新鲜不会被误伤。如果/tmp的容量还是不够可以重启一下机器Linux系统重启会默认清空/tmp下的文件。3.3 日志文件与容器空间的回收技巧日志往往是磁盘空间的隐形杀手。在排查时我会先看两个地方du -sh /var/log/* | sort -rh | head -10日志文件如果确认是历史遗留可以清理。对于正在被进程写入的日志直接删除文件不会释放空间进程还持有句柄建议用truncate清空而不是rmtruncate -s 0 /var/log/某个服务.logtruncate -s 0会把指定文件的大小改成0字节但保留文件本身的inode和文件描述符正在写入的进程不会受到影响。容器环境下的空间回收按下面的顺序来docker image prune -a docker container prune docker volume prunedocker image prune -a会删除所有未被任何容器使用的镜像docker container prune清掉所有已停止的容器docker volume prune删除没有容器使用的卷。这一套组合拳下来一般能回收可观的空间。做完之后别忘了用docker system df确认空间回收效果。3.4 用户目录常见占用大头一瞥在我大量排查这类故障的经验里用户目录下常见的空间占用大户主要有三类~/.cachepip、conda、Hugging Face等工具都会往这里写缓存。特别是Hugging Face的模型下载缓存动辄几个G甚至几十G。~/.local很多以--user方式安装的Python包会放在这里还有一些编辑器插件的扩展数据。~/miniconda3或~/anaconda3conda本体以及它的所有环境都在这里环境多了之后空间消耗十分可观。自查时可以直接从这个目录开始看占用du -sh ~/.cache ~/.local ~/miniconda3 2/dev/null如果发现~/.cache特别大可以先看看里面占用最多的是哪一项再针对性地删。比如huggingface的缓存可以按数据集或模型删除而不是整个目录清空。4. 拆解临时目录困局并解决多环境下载异常4.1 给临时目录单独扩容一边挂verified风险一边保构建速度在某些生产环境里/tmp挂在独立小分区上而且分区类型可能是tmpfs——也就是把内存当磁盘用。tmpfs的好处是速度快坏处是容量受内存限制。举个例子如果用一个小内存实例跑构建任务tmpfs默认大小可能是物理内存的一半在装PyTorch这种大包时临时文件很可能直接把tmpfs给撑爆。解决思路有几种一是将TMPDIR环境变量指向一个空间充足的目录。在运行安装命令前设置环境变量让pip把临时文件写到别处mkdir -p /data/tmp export TMPDIR/data/tmp pip install some-large-package注意设置TMPDIR时要确保目标目录所在分区有足够空间并且在目标目录里留足写入权限。bash或zsh用户还可以把export TMPDIR...写进~/.bashrc或~/.zshrc长期生效。但如果是为了排查临时问题不建议改全局配置排查完恢复默认更稳妥。二是对/tmp分区本身做扩容。如果/tmp是一个逻辑卷LVM可以用lvextend扩展容量如果它是一个独立磁盘分区可以调整分区表。但扩容操作涉及系统底层操作前务必确认自己有系统权限和备份否则在没把握的情况下优先使用改TMPDIR的方式更安全。4.2 缓存目录设到项目内换一种增量管理方式除了解决临时目录不够的问题缓存目录的迁移也是一种管理策略。如果你偏向更精细地控制缓存可以给pip指定缓存到项目内部目录pip install --cache-dir/project/.pip-cache some-package这样缓存放到了项目目录下不占系统分区空间。项目结束后可以随目录一起归档或者清理不会遗留一堆缓存垃圾在系统目录里。不过要注意如果项目目录本身在空间紧缺的分区上那这个方法会把问题转移到项目分区上。选择前先确认目标路径所在分区的剩余空间。4.3 处理多环境场景下的空间配置问题多环境场景下的空间管理比单环境要复杂一个维度。可能同时存在python venv、conda环境、还有pipenv或poetry的虚拟环境。这里分享几个我实际用过的策略先做总量确认用一条命令列出所有环境的体积du -sh ~/venv/* ~/miniconda3/envs/* ~/.venv/* 2/dev/null | sort -rh再针对不再使用的环境做删除。conda环境的删除命令是conda env remove -n 环境名如果只是临时不用某个环境并不想彻底删除可以把它打包成tar.gz存到对象存储或外部磁盘上需要时再解压还原。我一直在用的一种方式是给每个项目环境做一个干净需求清单环境里只装项目真正依赖的包不随手装各种调试工具。这样环境体积能小不少也有利于复现一致性。4.4 磁盘配额一个经常被忽略的隐藏约束在共享服务器上空间不足有时不是因为全盘满了而是账户配额被用完。用下面的命令检查当前用户是否设置了配额限制quota -s输出里如果显示No quotas running或者没有提示说明没有配额限制。但如果显示了usage和limit说明确实有配额。这种场景下无论怎么清理第三方缓存都没用必须删掉自己账户下的数据或者找管理员提高配额。我个人经验里在高校、实验室的共享集群上配额问题占比相当大而且排查起来容易走弯路。5. 根分区和其他分区的极限情形与系统视角5.1 根分区在上层目录被占满时的定向定位思路根分区被占满是最常见的一种死法。问题是根分区里半数的空间可能被那些你不一定知道的一级目录占用着。我找占用大头的思路是du -h --max-depth1 -x / 2/dev/null | sort -rh | head -20这条命令的作用是扫描根目录下的一级子目录按空间占用倒序排出前20名-x防止跨越挂载点。扫描结果出来后顺着最大的目录逐级往下追查。有些目录一眼能看出是干嘛的比如/var/lib/docker、/usr有些则需要进一步确认。在这个环节如果大量空间消耗源于某个服务的数据库或者日志可以针对性清理。我遇到过几次根分区占满是因为某个统计服务积累了海量日志没人处理。找到之后用truncate -s 0清空日志文件同时配置好日志轮转策略空间问题就迎刃而解了。5.2 文件系统层面的扩展与修复实操如果空间清理后仍然不能满足需求那就需要从文件系统层面做扩展了。这里分几种情况看LVM管理的根分区扩展逻辑卷的大小接着扩展文件系统。普通分区用分区工具调整分区大小需要先卸载或者使用支持在线扩展的方式。云主机在云控制台里先对磁盘扩容然后进入系统内部扩展分区和文件系统。以常见的ext4文件系统为例如果根分区是LVM逻辑卷扩展逻辑卷和文件系统的过程是lvresize -L 10G /dev/系统卷组名/根逻辑卷名 resize2fs /dev/系统卷组名/根逻辑卷名注意resize2fs对应ext4文件系统。如果你用的是XFS扩展命令要用xfs_growfsxfs_growfs /在还没有完全确认文件系统类型时先执行命令blkid或df -T查一下类型避免用错工具。对于云服务器场景控制台扩容磁盘后云厂商一般会有配套的扩展文档。核心步骤就是先在控制台把云盘扩容然后在系统内部重新扫描磁盘大小最后调整分区表和文件系统。5.3 系统盘目录瘦身建议哪些东西可以安全删除很多系统盘空间不足的机器上往往会躺着一些食之无味弃之可惜的组件。如果你也处在这样的状况里可以考虑优先清理下面这些内容旧版本内核内核更新后旧内核其实不会自动删除。可以执行apt autoremove或yum autoremove清理不再需要的内核包。但保留最近两三个版本的内核作为回退保证不建议全部清掉。apt/yum缓存apt-get clean和yum clean all清理的是软件包缓存不会影响已安装软件。/var/cache里面如果有构建缓存或下载缓存也可以删。systemd日志journalctl默认持久化存储在/var/log/journal下长期不清理会非常大。可以使用journalctl --vacuum-time30d把30天前的日志清掉或者--vacuum-size限制日志总大小这个命令按日志时间线清风险小。再做一层保护建议在清理前对关键配置做一份备份。比如/etc/fstab如果扩容后重启出现挂载异常这个文件可是救命的关键。5.4 特殊挂载导致的假满现象有一种情况特别迷惑df -h看着空间还剩很多安装包就是报空间不足。除了前面提到的inode问题外还有一种可能就是挂载选项里带了size限制。例如tmpfs挂载时可以指定大小mount -t tmpfs -o size1G tmpfs /some/path这样即使系统内存和磁盘都有大量空余/some/path分区却只能使用1G。遇到这种情况要把对应的挂载项在/etc/fstab里查找并调整其大小参数然后重新挂载。注意fstab的修改需要格外小心错误配置可能导致开机异常改之前先做好备份。6. 实用技巧与总结经验从应急到长远6.1 把大包依赖分层安装稳字当头在处理空间不足问题的过程中我发现一个实用的安装策略大依赖分层装比一把梭更稳。比如需要安装一个机器学习包加上一堆辅助库可以把最占空间、最可能出问题的包先单独安装确认通过后再安装其他小包。这样如果中途出现空间不足报错点会更明确不会因为所有包同时下载解压把临时空间瞬间吃光。同时单独安装大包能让缓存分得更清以后需要针对性清理时也更方便。6.2 给磁盘空间做监控和预警空间问题的处理是应急更重要的是预防。我通常会在生产环境配置一个简单的磁盘监控脚本每10分钟检查一次使用率超过阈值就告警#!/bin/bash CURRENT$(df / | awk NR2{print $5} | sed s/%//g) if [ $CURRENT -gt 85 ]; then echo 磁盘使用率超过85%$CURRENT% fi把这个脚本加入crontab让它每10分钟执行一次。阈值可以根据自己的情况调但对于生产环境我个人习惯在80%到85%的时候就开始处理不要真等到打满再抢救。同时把日志轮转配置好无论用logrotate还是其他方案确保日志不会无限增长。6.3 安全交叉自检真实复盘这个报错看似只有一句话但背后涉及的问题分层非常多。第一层磁盘空间真的不够了。直接用df -h就能判断。第二层存在小分区或独立挂载点限制了某个目录的使用。查df -h的输出要逐个挂载点看。第三层inode耗尽。用df -i验证。第四层挂载参数或配额限制了写入。检查挂载选项和配额设置。第五层容器层、镜像层堆积导致的写入困难。用docker system df检查。如果按这个顺序排查基本能把问题定位到具体环节不会绕弯路。6.4 一个小习惯装包前先看空间最后分享一个值得培养的习惯在安装任何大型软件包之前先看一下空间和临时目录的情况几十秒的事情却能省下后面白折腾的大把时间。习惯成自然之后这套流程就像肌肉记忆一样顺滑。df -h /tmp /加上df -i两条命令在同一屏输出把关键信息一次看全。如果是容器环境再顺手加一条docker system df。养成这个习惯后再遇到[Errno 28]的概率会低很多就算遇到也知道从哪个方向排查。这套方法在数据分析环境、Web服务环境、深度学习训练环境上都验证过适用场景覆盖得挺广。你可以在自己的机器上对照着做一次全面检查把隐患提前解决掉。