1. 问题背景与紧急处理思路
作为一名长期使用Jetson系列开发板的嵌入式开发者，我最近在Jetson Orin上遇到了一个典型问题：系统盘空间被完全占满导致无法正常启动图形界面。这种情况在资源受限的边缘计算设备上并不罕见，特别是当我们频繁安装开发工具、积累日志文件或进行大量数据缓存时。
当系统盘使用率达到100%时，最直接的表现就是：
- 无法启动图形用户界面（卡在登录循环或黑屏）
- 终端命令响应极慢甚至无响应
- 系统服务异常崩溃
此时常规的SSH连接往往也会失效，因此我们需要通过物理串口连接来访问系统。Jetson Orin提供了方便的调试串口（通常是J41接头），这是工程师最后的救命稻草。我手头正好有USB转RS232的串口线（市面上常见的PL2303或CH340芯片都可用），配合MobaXterm这类支持串口连接的终端工具，就能建立紧急救援通道。
提示：Jetson Orin的串口默认配置通常是115200波特率，8数据位，1停止位，无校验位（115200-8-N-1）。连接前请确保线序正确，TX/RX不要接反。
2. 系统诊断与空间分析
通过串口成功登录后，第一件事就是确认磁盘空间状态。df -h命令是Linux系统管理的瑞士军刀，它能直观显示各挂载点的使用情况：
bash复制$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 58G 58G 0 100% /
tmpfs 16G 0 16G 0% /dev/shm
从输出可以清晰看到根分区（/）已经爆满。接下来需要找出具体的"空间大胃王"，这里推荐使用ncdu工具（如果没有安装，可以先通过串口安装）：
bash复制sudo apt install ncdu -y
ncdu /
这个命令会扫描整个文件系统，并以交互式界面显示各目录占用空间大小。在我的案例中，发现以下几个常见的高占用目录：
/var/log- 系统日志堆积（特别是长期运行的docker容器日志）/var/cache/apt- apt软件包缓存~/.cache- 用户级缓存文件/usr/local/cuda-xx.x- 旧版CUDA工具链残留
3. 系统清理实战手册
3.1 清理APT缓存与无用软件包
Ubuntu系的包管理系统会在/var/cache/apt/archives保留所有下载过的deb包，这是最先应该清理的目标：
bash复制# 清理已下载的安装包
sudo apt clean
# 自动移除不再需要的依赖包
sudo apt autoremove -y
# 额外技巧：清理旧版本内核（Jetson系统常有多余内核）
sudo apt purge $(dpkg -l | awk '/^ii linux-/{print $2}' | grep -v $(uname -r))
注意：在资源紧张的设备上，建议定期将
apt autoremove加入维护脚本。我曾经遇到过因为自动更新积累的旧内核占用数GB空间的情况。
3.2 日志文件精简化管理
系统日志是另一个空间杀手，特别是长期运行的服务器应用。Journald的日志压缩功能非常实用：
bash复制# 将系统日志压缩到100MB以内
sudo journalctl --vacuum-size=100M
# 如果使用docker，清理容器日志（这是个常见隐藏问题）
sudo find /var/lib/docker/containers/ -name "*.log" -exec truncate -s 0 {} \;
# 还可以设置日志轮转策略
sudo nano /etc/logrotate.conf
在我的实践中，发现Docker容器的JSON日志文件经常失控增长。除了手动清理外，更好的方法是在/etc/docker/daemon.json中配置日志大小限制：
json复制{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}
3.3 开发环境缓存清理
Python开发中产生的缓存文件也值得关注：
bash复制# 清理pip缓存
rm -rf ~/.cache/pip
# 清理Python编译生成的__pycache__
find . -type d -name "__pycache__" -exec rm -rf {} +
# 如果使用conda，清理包缓存
conda clean --all
对于CUDA开发者，旧版本的Toolkit往往会留下大量文件。在确认不需要旧版本后：
bash复制sudo apt purge cuda-10-2 cuda-11-1 # 示例版本号
sudo /usr/local/cuda-11.1/bin/uninstall_cuda_11.1.pl # 运行对应卸载脚本
3.4 深度清理技巧
除了上述常规清理，还有一些进阶方法：
- 查找大文件：
bash复制find / -type f -size +100M -exec ls -lh {} \;
- 清理缩略图缓存：
bash复制rm -rf ~/.cache/thumbnails/*
- 检查异常的spool文件：
bash复制sudo rm -f /var/mail/*
sudo rm -f /var/spool/mail/*
- 清理旧的snap包：
bash复制sudo snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do
sudo snap remove "$snapname" --revision="$revision"
done
4. 预防措施与自动化方案
经历过几次紧急清理后，我总结了一套预防性维护方案：
4.1 磁盘空间监控脚本
创建一个定期运行的监控脚本/usr/local/bin/disk_monitor.sh：
bash复制#!/bin/bash
THRESHOLD=90
CURRENT=$(df / --output=pcent | tail -1 | tr -d '%')
if [ "$CURRENT" -ge "$THRESHOLD" ]; then
echo "WARNING: Root filesystem usage $CURRENT% exceeds $THRESHOLD%" | \
mail -s "Disk Space Alert" admin@example.com
# 自动触发清理
apt clean
journalctl --vacuum-size=200M
fi
然后添加到cron每周运行：
bash复制sudo chmod +x /usr/local/bin/disk_monitor.sh
sudo crontab -e
# 添加：
0 3 * * 0 /usr/local/bin/disk_monitor.sh
4.2 合理的分区方案
对于新装系统，建议采用更科学的分区方案：
/根分区：至少40GB（建议60GB）/home：单独分区便于备份/var：单独分区防止日志爆满影响系统
4.3 日志管理策略
配置/etc/systemd/journald.conf：
ini复制[Journal]
SystemMaxUse=500M
RuntimeMaxUse=200M
对于关键服务，使用logrotate配置轮转：
conf复制/var/log/myapp/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 640 root adm
}
5. 疑难问题排查记录
在实际操作中，可能会遇到一些特殊情况：
案例1：清理后空间未释放
- 可能原因：有进程仍持有已删除文件的句柄
- 解决方案：
bash复制# 查找已删除但未释放的文件
sudo lsof +L1
# 重启相关服务或系统
# 也可以使用更专业的工具
sudo apt install smem
smem --pie=command -s pss
案例2：/run目录占用异常
- 通常是因为临时文件堆积
- 解决方案：
bash复制sudo systemctl stop systemd-journald
sudo rm -rf /run/log/journal/*
sudo systemctl start systemd-journald
案例3：Docker存储驱动问题
- 检查devicemapper或overlay2占用：
bash复制docker system df
docker system prune -a --volumes
经过这些系统化的清理和维护，我的Jetson Orin现在稳定运行在磁盘使用率70%以下。最关键的是建立了预防性维护习惯，再也不用面对无法启动的紧急情况了。对于边缘计算设备，资源管理本身就是开发者的必修课，希望这些实战经验能帮到同样使用Jetson平台的同行们。