Jetson Orin Nano存储扩容实战：将/home迁移至reComputer

1. 项目缘起为什么要把Orin Nano的/home挪到reComputer上最近在折腾Jetson Orin Nano Developer Kit这玩意儿性能是真不错但有个老问题又冒出来了内置的eMMC存储空间实在不够看。我装了几个开发环境比如PyTorch、TensorRT再拉几个数据集/home目录很快就告急了。每次编译点东西或者处理数据都得小心翼翼生怕把存储写满导致系统卡死。这严重影响了开发效率尤其是在做需要大量中间文件的AI模型训练或数据处理时。于是我想到了手头另一台设备reComputer。它通常有更大的存储空间无论是SATA SSD还是NVMe容量和速度都比Orin Nano自带的eMMC强不少。把/home这个用户数据和配置文件最集中的地方迁移过去听起来是个一劳永逸的方案。这不仅能解决空间瓶颈还能利用reComputer可能更好的I/O性能提升开发体验。更重要的是这种架构让Orin Nano专注于计算存储交给reComputer有点小型工作站的味道了。但迁移/home不是简单的复制粘贴。它涉及到系统用户、权限、正在运行的进程以及大量应用程序的配置文件。操作不当轻则登录不了桌面重则系统无法启动。网上搜了一圈发现大家踩的坑五花八门从权限错乱到服务启动失败什么都有。所以我决定把这次从Jetson Orin Nano到reComputer的/home数据迁移全过程包括原理、步骤、踩的坑和最终验证详细记录下来。2. 迁移前的核心准备环境分析与方案设计动手之前必须先搞清楚现状和目标。盲目操作是数据灾难的开始。2.1 源与目标设备状态确认我的源设备是Jetson Orin Nano Developer Kit系统是JetPack 5.1.2基于Ubuntu 20.04。使用df -h命令查看发现根分区/和/home同在一个分区这是NVIDIA官方镜像的默认布局。总容量约60GB/home已经使用了40多GB。目标设备是一台reComputer我给它装了一块1TB的NVMe SSD并安装了与Orin Nano相同版本的Ubuntu 20.04系统以确保库文件版本一致减少兼容性问题。首先需要在两台设备间建立稳定、高速的网络连接。最可靠的方式是通过千兆以太网直连或者连接至同一个局域网交换机。我选择用网线将两台设备直接相连并手动配置了静态IP地址避免DHCP可能带来的不稳定性。Orin Nano (源): 192.168.1.100reComputer (目标): 192.168.1.101配置完后立即用ping命令测试连通性确保网络链路通畅。2.2 迁移工具选型为什么是rsync迁移大量文件cp或scp不是最佳选择。cp在中断后无法续传scp虽然能跨网络但效率相对较低且缺乏完整性校验。我选择rsync这是此类任务的行业标准工具理由如下增量同步与断点续传rsync只传输源和目标之间有差异的文件部分首次是全量之后若需重试或同步更新速度极快。网络不稳定时重新执行命令即可续传。保持属性通过-aarchive参数可以完美保留文件的权限permission、所有权owner/group、时间戳modify time、符号链接symbolic link等所有元数据。这对于/home目录至关重要因为很多应用程序依赖特定的文件权限和属主才能正常运行。安全与验证支持SSH加密传输并且传输结束后可以校验文件一致性。试运行模式-ndry-run参数可以模拟执行列出将会发生的变化而不实际传输用于最终检查避免误操作。因此核心命令骨架确定为rsync -avz --progress -e ssh /home/ userrecomputer-ip:/path/to/new/home/。其中-z用于压缩传输数据节省带宽--progress显示实时进度。2.3 关键预处理清理、备份与用户处理在按下回车键开始同步之前还有几件必须做的事1. 源端(/home)清理运行du -sh /home/* | sort -hr查看/home下各个用户目录的大小。我发现有很多缓存文件如.cache、临时文件、旧的下载包和Docker镜像占用了大量空间。我清理了浏览器缓存、pip和conda的缓存包pip cache purge,conda clean --all并移除了不再需要的Docker容器和镜像。这一步为我腾出了近10GB空间减少了不必要的传输量。2. 完整系统备份这是最重要的保险措施。即使操作再小心也有意外可能。我使用dd命令将Orin Nano的整个eMMC备份到了一个外接USB硬盘上。sudo dd if/dev/mmcblk0 of/media/usb-backup/orin-nano-full-backup.img bs4M statusprogress这条命令将整个存储设备逐块备份成镜像文件。万一迁移失败导致系统崩溃我可以利用这个镜像快速恢复。3. 处理已登录用户和进程迁移/home时必须确保没有程序正在读写其中的文件。最稳妥的方式是进入单用户模式或恢复模式。对于Jetson Orin Nano我选择在开机时进入GRUB菜单选择“Advanced options”再选择“recovery mode”然后进入“root”命令行。这样系统只有最基础的服务运行所有普通用户都已退出可以安全地操作/home目录。如果无法进入恢复模式则必须手动确保所有用户已注销。通过who命令查看登录用户用pkill -KILL -u username强制结束相应用户的所有进程。但请注意这会导致该用户所有未保存的工作丢失务必提前通知。3. 分步实施从挂载、同步到切换准备工作就绪后我们进入核心操作阶段。这个过程需要严格按照顺序执行。3.1 在reComputer上准备目标存储位置我的目标是在reComputer的1TB NVMe SSD上专门划出一个分区来承载新的/home。假设这块SSD在系统中识别为/dev/nvme0n1。分区使用fdisk或parted工具。我选择parted因为它对GPT分区表更友好。sudo parted /dev/nvme0n1 (parted) print # 查看现有分区布局 (parted) mkpart primary ext4 1GB 100% # 创建一个从1GB开始到磁盘末尾的主分区预留前1GB可能用于其他用途如boot (parted) set 1 lvm on # 可选如果打算用LVM可以设置标志 (parted) quit然后格式化新分区为ext4文件系统兼容性好日志式sudo mkfs.ext4 /dev/nvme0n1p1创建临时挂载点并挂载我们不直接挂载到/home先挂载到一个临时位置进行数据同步。sudo mkdir -p /mnt/new_home sudo mount /dev/nvme0n1p1 /mnt/new_home挂载后使用df -h确认挂载成功并看到正确的容量。初始化目标目录结构在/mnt/new_home下我们需要创建与源/home相同的用户目录骨架并确保权限正确。最简单的方法是先同步空目录结构。# 在Orin Nano源上执行假设我们已经通过恢复模式root登录 rsync -av --dry-run /home/ /mnt/new_home/ # 先模拟看输出但更关键的是在reComputer上我们需要先手动创建/mnt/new_home目录并设置正确的所有权给root因为rsync会保持这个顶层的权限。3.2 执行首次全量数据同步这是最耗时的一步。在Orin Nano的恢复模式root shell下执行真正的同步命令。注意我们使用-e ssh指定通过SSH传输前提是已经在两台机器间配置了SSH密钥免密登录否则需要多次输入密码。# 在Orin Nano上执行 rsync -avz --progress -e ssh /home/ root192.168.1.101:/mnt/new_home/参数解释-a: 归档模式保持所有属性。-v: 详细输出让你看到正在同步的文件。-z: 传输时压缩节省网络时间。--progress: 显示每个文件的传输进度。-e ssh: 使用SSH作为远程shell。执行过程中的注意事项网络稳定性确保网线连接牢固。如果中断重新执行相同的rsync命令即可它会自动跳过已传输的相同文件实现续传。权限问题如果遇到rsync: failed to set permissions on ...: Operation not permitted (1)之类的警告通常是因为目标文件系统如某些NAS或特定挂载参数不支持完整的Linux权限。我们的目标是ext4所以应该没问题。如果出现可以尝试加上--no-perms和--no-owner参数但这是下策会破坏权限结构后续需要手动修复。跳过特定文件可以使用--exclude参数排除一些临时或缓存目录如--exclude.cache --exclude.Trash以加快速度。但首次全量同步我建议包含所有内容确保一致性。同步完成后在reComputer上检查/mnt/new_home目录确认所有用户文件夹、隐藏配置文件都已存在并且ls -la显示的文件属主和权限与源端基本一致。3.3 修改reComputer的fstab实现自动挂载数据同步到位后需要让reComputer在每次启动时自动将新的分区挂载到/home。获取新分区的UUID使用blkid命令。sudo blkid /dev/nvme0n1p1输出类似/dev/nvme0n1p1: UUIDa1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 TYPEext4记下这个UUID用它来标识分区比用/dev/nvme0n1p1更稳定因为设备名可能会变。备份并编辑/etc/fstab文件sudo cp /etc/fstab /etc/fstab.backup.$(date %Y%m%d) sudo nano /etc/fstab在文件末尾添加一行UUIDa1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 /home ext4 defaults,nofail 0 2UUID...: 用你实际的UUID替换。/home: 挂载点。ext4: 文件系统类型。defaults: 默认挂载选项包括rw, suid, dev, exec, auto, nouser, async。nofail: 非常重要即使启动时该分区不存在或无法挂载系统也会继续启动防止因存储设备未就绪导致系统卡在启动界面。0 2: 最后一个数字2表示非根分区需要dump工具备份和fsck检查顺序。测试fstab配置 在真正挂载到/home之前先测试语法是否正确并尝试挂载到一个临时位置。sudo mount -a # 挂载fstab中所有未挂载的分区如果没有报错再用df -h查看新分区是否已挂载到我们指定的临时位置如果之前没卸载的话。现在不要直接挂载到/home因为那里可能还有老数据。3.4 切换挂载点关键时刻的操作这是最紧张的一步。我们需要将reComputer上原有的/home内容移走备份然后将新分区挂载上去。在reComputer上操作 首先确保所有用户已注销。切换到单用户模式或使用一个非/home目录下的root shell例如通过ssh从另一台机器登录或者使用CtrlAltF3进入TTY3终端以root登录。备份旧的/home并挂载新的/home# 进入单用户模式后执行以下命令 cd / # 将旧的/home目录重命名备份以防万一 mv /home /home.old.backup # 创建新的空/home目录作为挂载点 mkdir /home # 将新分区挂载到/home mount /dev/nvme0n1p1 /home # 立即检查挂载是否成功 ls -la /home你应该看到从Orin Nano同步过来的所有用户数据。此时/home.old.backup里是reComputer原来的用户目录如果有的话。验证并重启 快速验证几个关键点能否切换到某个迁移过来的用户su - username该用户的环境变量是否正常家目录下的配置文件如.bashrc是否存在。确认无误后重启reComputer进入正常的多用户模式。reboot重启后正常登录图形界面或SSH检查/home下的文件是否完好用户桌面、文档、应用程序配置是否都正常。4. 迁移后的验证、问题排查与优化系统成功启动并登录只是第一步。我们需要进行一系列验证确保迁移完全成功并解决可能出现的后续问题。4.1 基础功能验证清单我制定了一个检查清单逐一验证文件系统与容量df -h /home确认挂载点正确显示的是新分区1TB的容量而不是原来的小分区。用户与权限ls -la /home检查各用户目录的所有者owner和组group是否与Orin Nano上一致。例如用户jetson的目录应该属于jetson:jetson。如果出现属主变成root或数字UID说明同步时权限未保持需要手动修复sudo chown -R username:username /home/username。用户登录与环境分别用每个迁移过来的用户登录SSH或本地。检查家目录是否正常echo $HOME应输出/home/username。检查基础Shell配置cat ~/.bashrc看内容是否完整。测试用户专属的应用程序配置是否生效。例如对于开发者检查git config --global --list是否还能看到之前的配置。应用程序兼容性测试Python环境激活原有的conda或venv环境运行一个简单的Python脚本看是否报错。常见错误是虚拟环境的python可执行文件路径硬编码了旧的/home路径但我们的/home挂载点没变所以通常没问题。但如果虚拟环境是在不同架构如x86_64上创建的在ARM的Orin Nano或reComputer上可能无法直接运行需要重建。Docker运行docker ps检查Docker服务是否正常。Docker的镜像和容器默认存储在/var/lib/docker不受/home迁移影响。但用户目录下的docker-compose.yml等配置文件应能正常读取。桌面环境登录图形界面检查桌面壁纸、图标布局、自启动程序是否都保留了下来。4.2 常见问题与根因排查在实际操作中我遇到了几个典型问题以下是排查思路问题一用户登录后提示“无法创建家目录”或“权限被拒绝”。现象SSH登录时提示Could not create directory /home/username/.ssh或者登录后提示某些配置文件无法读取。根因目标分区/dev/nvme0n1p1的挂载属性或文件系统权限有问题导致非root用户无法在自己的家目录下写文件。排查检查挂载选项mount | grep /home。确保没有noexec,nosuid, 或特别是nouser这会导致只有root能操作。我们的fstab里用的是defaults通常包含user或users允许普通用户挂载不defaults不含user。实际上对于/homedefaults就够了因为目录本身的权限由文件系统控制。检查家目录的权限ls -ld /home/username。应该是drwxr-xr-x或drwx------所有者是username。如果所有者是root则需要用chown修复。检查/home目录本身的权限ls -ld /home。应该是drwxr-xr-x root root。问题二应用程序报错“找不到库”或“可执行文件格式错误”。现象类似热词中提到的bash: /home/wyl/miniconda3/envs/lerobot/bin/ffmpeg无法执行二进制文件: 可执行文件格式错误。根因这个错误通常与/home迁移无关而是二进制文件架构不匹配。如果这个ffmpeg是从x86_64的机器上复制过来的conda环境中的那么在ARM64架构的Jetson Orin Nano或reComputer上就无法执行。解决方案确认设备架构uname -mJetson是aarch64。为当前架构重新安装该软件包。对于conda环境可以尝试conda install ffmpeg -c conda-forgeconda会自动选择ARM64版本的包。如果整个虚拟环境都是跨架构迁移的最稳妥的方法是重建环境使用针对ARM64的包源。问题三系统启动时卡住提示“Failed to mount /home”或进入紧急模式(emergency mode)。根因/etc/fstab配置错误或者新分区UUID在启动时尚未就绪在复杂的磁盘阵列或USB连接存储中常见。排查在启动时按Esc或Shift进入GRUB选择恢复模式以root身份登录。检查/etc/fstab中UUID是否正确blkid对比。检查分区是否存在lsblk -f。尝试手动挂载mount /dev/nvme0n1p1 /mnt看具体报错信息。可能是文件系统损坏运行fsck或者分区类型不对。关键技巧fstab中的nofail选项就是为了防止此问题。如果没加加上它。如果已经加了但还卡住可能是系统在等待超时。可以尝试在defaults后加上,nofail,x-systemd.device-timeout5将超时时间设为5秒。4.3 性能优化与后续维护建议迁移完成后还可以做一些优化让新/home跑得更快、更稳。文件系统挂载选项优化 编辑/etc/fstab针对SSD优化挂载参数。将原来的defaults改为更具体的选项UUIDxxxx /home ext4 defaults,noatime,nodiratime,discard,errorsremount-ro 0 2noatime,nodiratime禁止记录文件的访问时间减少不必要的写操作显著提升I/O性能对SSD寿命也有好处。绝大多数应用不需要atime。discard启用TRIM功能让SSD在删除文件时能及时回收存储块保持长期性能。但注意有些老内核或特定SSD搭配discard可能有问题。更稳妥的做法是定期用fstrim命令手动TRIM如加入cron每周执行。errorsremount-ro当文件系统出现错误时以只读方式重新挂载防止数据损坏。定期备份策略 现在数据集中在reComputer的大容量SSD上定期备份更为重要。我设置了一个简单的rsync备份脚本通过cron每周自动执行将/home增量同步到另一台NAS或大容量硬盘上。# 示例备份脚本 /usr/local/bin/backup_home.sh #!/bin/bash rsync -av --delete /home/ usernas-ip:/path/to/backup/location/ --exclude.cache --exclude*.tmp记得给脚本加执行权限并在/etc/crontab中添加任务。监控磁盘健康 对于NVMe SSD可以安装nvme-cli工具定期检查SMART健康状态。sudo apt install nvme-cli sudo nvme smart-log /dev/nvme0关注percentage_used使用寿命百分比和critical_warning等关键指标。5. 延伸思考这种架构的优劣与适用场景完成这次迁移后我对这种“计算与存储分离”的微型工作站架构有了更深体会。它并非适用于所有场景但有其独特的价值。优势突破嵌入式设备存储瓶颈这是最直接的收益。Jetson等嵌入式开发板为了尺寸和功耗通常配备有限的eMMC。将/home外迁相当于解除了存储限制可以存放大型数据集、模型文件、日志等。便于数据集中管理与备份所有开发数据都在reComputer的单一分区上备份、迁移、版本管理都变得更简单。甚至可以在reComputer上搭建GitLab或文件共享服务供团队协作。潜在的升级灵活性如果未来reComputer的存储不够了可以很方便地更换更大容量的硬盘或者升级为RAID阵列、更快的PCIe 4.0 SSD而无需动Jetson主板。隔离风险Jetson系统盘只保留核心系统变得更“干净”。即使Jetson系统崩溃需要重刷/home数据在另一台设备上安然无恙重装系统后重新挂载即可。劣势与注意事项单点故障转移reComputer成了数据单点。如果它的硬盘损坏或设备故障所有数据都会丢失。因此必须实施严格的备份策略如上面提到的。网络依赖与性能/home的访问速度现在受限于网络带宽千兆以太网约110MB/s和reComputer的磁盘I/O。对于需要极高磁盘IOPS的应用如高频数据库读写这可能成为瓶颈。考虑使用万兆网络或直接通过PCIe连接存储可以缓解但成本增加。复杂度提升系统从一个自包含的设备变成了两个设备相互依赖。配置、维护、故障排查的复杂度都增加了。需要确保reComputer在Jetson启动前就绪。用户习惯一些应用程序或脚本可能硬编码了路径假设。虽然/home挂载点没变但如果脚本里写了类似/media/old_home的路径就会出错。迁移后需要对所有自动化脚本进行检查。适用场景建议AI模型训练与数据科学需要在Jetson上处理大量本地数据的项目。长期运行的边缘计算节点产生大量日志和结果数据需要存储。多项目、多环境开发开发者需要在同一台Jetson上切换多个项目每个项目都有独立的虚拟环境和数据。作为小型服务器将Jetson reComputer组合作为一个轻量级服务器提供持续服务。不适用场景对启动速度和可靠性要求极高的工业现场额外的网络挂载会增加启动失败的风险和启动时间。设备需要频繁移动或断电两个设备的连接和供电会变得麻烦。存储IO是绝对性能瓶颈的应用网络延迟和带宽可能无法满足需求。最后我个人在实际操作中的体会是规划比操作更重要。花时间设计好分区方案、网络配置、备份策略能避免后续无数麻烦。这次迁移过程中因为提前做了完整备份我在测试fstab配置时即使不小心写错参数导致启动失败也能从容地从备份镜像恢复心态完全不一样。对于在Jetson这类资源受限但计算强大的设备上进行长期开发的同行来说将/home外挂到一个更可靠的存储上是一个值得考虑的、能显著提升幸福感的方案。