1. 飞牛NAS的系统分区与存储空间到底是什么关系很多刚上手飞牛系统fnOS的朋友遇到的第一道坎不是装系统而是用着用着突然发现系统盘红了。明明自己只存了几部电影、跑了一两个Docker容器怎么系统分区就满了更麻烦的是在后台点来点去也没找到“把系统空间挪到存储空间”的入口于是就开始搜“飞牛系统分区迁移空间至存储空间 1”之类的关键词。先别急着操作我先把飞牛的存储逻辑捋清楚。飞牛系统在安装时默认会把系统装在一块硬盘上并且会在这块盘上划出几个独立分区引导分区、系统分区、交换分区这些分区各自承担系统启动、核心文件和内存交换的职责。这部分空间是给系统本身用的不是给你存影视资源的。而在剩余空间里飞牛会创建存储空间默认可能叫“存储空间 1”这部分才是你平时放照片、视频、Docker数据的地方。问题就出在这套默认分配逻辑上。飞牛系统分区默认给的容量并不宽裕一般只有几十GB甚至在某些镜像里只给十几个GB。而系统分区里实际上会承担很多额外写入任务系统更新缓存、Docker的镜像和容器日志、日志系统journald、临时文件、应用数据都会往系统分区里塞。我见过不少人装完系统没几个月系统分区占用率直接飙到90%以上然后系统开始疯狂告警Web界面打不开、应用启动失败、文件服务卡顿甚至连关机都变得异常缓慢。那“分区迁移空间至存储空间 1”这个需求本质上就是想干两件事要么把系统分区和存储空间1之间的空间重新做平衡要么把系统分区里那些吃空间的大头目录迁移到存储空间1去让系统分区瘦身。但问题是很多人的设备里系统盘和存储空间1根本是两块不同的硬盘物理位置都不在一起“迁移空间”就不是拖动一下滑块那么简单了。所以这篇文章我会把几种可行的迁移思路都拆开讲清楚LVM逻辑卷扩容、目录迁往存储空间1、以及相关挂载与校验操作。全程按照我实际操作过的流程来写不绕弯子也不整玄学。1.1 飞牛默认安装分区结构系统盘为什么总是不够用要给系统做空间迁移第一步是先看懂自己的分区结构。飞牛基于Linux内核安装在实体机或虚拟机上都支持默认分区方案大致是这样/boot引导分区一般只有几百MB到1GB装内核和引导文件。/系统根分区也就是系统盘的主要分区飞牛默认给的大约20GB到50GB不等。swap交换分区内存不够时的后备缓冲。剩余空间用于构建存储空间通常挂载在/vol1、/vol2这类路径下。注意这里的“剩余空间”如果和系统根分区在同一块物理硬盘上那么飞牛在安装时会自动把剩余空间做成存储空间不需要你手动处理。如果你的机器上只有一块盘那么存储空间1和系统分区都在同一块SSD或机械硬盘上只是不同的分区而已。听起来是不是很简单但问题恰恰出在“同一块盘”和“不同分区”上。因为系统分区是固定大小的你在飞牛安装完成后就算存储空间1还有大量空闲系统分区也无法自动“借用”这些空间。而系统分区一旦被日志、Docker镜像、更新包塞满系统整体的稳定性就会受到影响。我在实际维护中遇到的最典型一个案例是一台装了飞牛的小主机硬盘总共512GB系统分区30GB存储空间1约450GB。结果用户把Docker的数据目录默认放到了/var/lib/docker这正好在系统分区里跑了一个下载容器几天就写了30GB的临时数据直接干爆了根分区整个Web服务挂掉。这就是典型的“空间分配不合理”引发的故障。所以在动手迁移之前你至少要会用三个命令来确认当前状态df -hT lsblk cat /etc/fstabdf -hT能告诉你每个分区的文件系统类型和使用率lsblk能展示完整的磁盘和分区树状结构cat /etc/fstab则是查看系统启动时的挂载规则后面做绑定挂载时肯定用得到。1.2 系统空间告急的典型症状与元凶定位再说说系统分区满了之后会出现什么症状。它的表现不是单纯的“存储空间不足”提示而是一连串连锁反应Web管理界面能进但点击“应用中心”或“Docker”页面时半天无响应日志疯狂刷写失败容器反复重启SMB/NFS共享服务突然中断局域网内访问不到文件系统设置中显示“系统分区已满”但存储空间1却显示正常更严重的重启后系统进入维护模式无法正常启动。为什么系统分区满了影响这么大因为Linux系统的正常运行极度依赖根分区的可用空间。很多服务都要在运行时写临时文件、写缓存、写socket一旦根分区满了这些服务就会集体罢工。你可以把系统分区理解成家里的门厅过道存储空间是卧室和车库。门厅堆满杂物你连走到卧室的通道都没了更别说把车开进来。找到症状之后就要定位“元凶”。大多数情况下空间的大头无非这么几个目录/var/lib/dockerDocker的默认数据目录镜像、容器层、卷数据都在这里/var/log系统日志journald日志长期不清理会非常可观/tmp临时文件某些应用崩溃后残留的大文件/var/cache软件包缓存和更新缓存/home下如果有用户数据且没有挂载到存储空间也会占系统盘。快速定位元凶很简单一句命令即可du -h --max-depth1 / 2/dev/null | sort -h按目录大小从下往上排序看一眼就能知道是谁在偷偷吃空间。我遇到的情况里Docker数据占据比例最高其次是journald日志剩下的就是系统更新缓存。定位清楚之后你才好决定自己到底用哪种迁移方案。2. 迁移思路选型扩容、搬家还是重新规划搞清楚系统分区为什么满之后下一个问题就是怎么把它“救回来”。我现在能想到的可行办法大致有三种LVM逻辑卷扩容前提是你的系统盘用的是LVM管理并且存储池里有可用的物理卷空间或者能把存储空间1的部分空间释放出来加入系统卷组然后在线扩展根分区。目录迁移把/var/lib/docker、/var/log这类吃空间的大目录用rsync搬到存储空间1再用绑定挂载的方式让系统继续按原路径访问。重装系统并重新规划分区这是最粗暴、但也是数据风险最高的办法只建议在设备还没存重要数据时使用。三种办法各有利弊不能一概而论。我在下面分别展开。2.1 方案ALVM逻辑卷在线扩容LVM全称 Logical Volume Manager是Linux下非常成熟的磁盘管理机制。它的核心理念就是把物理磁盘抽象成物理卷PV、卷组VG和逻辑卷LV三层。逻辑卷的大小可以在线调整只要卷组里有足够的剩余空间。飞牛系统在部分安装场景下确实启用了LVM系统分区就是挂在一个名为fnOS_vg之类的卷组下的逻辑卷。这种情况下理想的扩容路径是找到一块有剩余空间的物理卷或者干脆把存储空间1所在磁盘释放出未分配区域做成新的物理卷把物理卷加入系统卷组用lvextend扩大根逻辑卷用resize2fs或xfs_growfs扩大文件系统。这个方案的优点在于可以实现“热扩容”系统不用重启逻辑卷扩大后文件系统也随之扩大整个过程对正在运行的服务几乎没有影响。缺点在于如果你的系统盘根本不是LVM管理的这个方案就没法用只能走目录迁移。而且LVM扩容还牵扯到一个很实际的约束存储空间1是否和系统在同一个卷组如果不是你得先把存储空间1里的数据腾出去再把那块物理磁盘缩容或重新分区操作复杂度会直线上升。所以动手之前务必用pvscan、vgscan、lvscan确认当前的LVM拓扑。2.2 方案B重负载目录迁移到存储空间1如果LVM路线走不通或者你只是单纯不想动分区表那目录迁移就是最稳妥的替代方案。它的核心逻辑是系统分区之所以紧张是因为某些目录数据量太大而这些数据并不一定要放在系统盘上。我们把它们整体搬到存储空间1然后在原路径上做一个“绑定挂载”bind mount让系统以为数据还在原处。这里以最常出问题的 Docker 数据目录为例迁移流程可以概括为systemctl stop docker rsync -aXS /var/lib/docker/ /vol1/docker/ mount --bind /vol1/docker /var/lib/docker systemctl start docker这套操作的优点非常明显不需要动分区表不依赖LVM只要你存储空间1有足够容量就能执行。而且可迁移的目录不限于Docker日志目录、下载缓存目录、应用数据目录都可以如法炮制。缺点呢就是路径绑定这件事需要在系统重启后依然生效所以你必须把挂载规则写进/etc/fstab。如果只敲了mount --bind但没写fstab系统一重启绑定关系就没了服务会再次找到原来那个几乎是空的目录到时候表现出来的就是“数据不见了”的假象。2.3 三种方案怎么选对比与适用场景这里我把三种方案整理成一张表格方便你对照自己的设备情况做判断方案前提条件操作复杂度数据风险适用场景LVM在线扩容系统使用LVM有可用物理卷空间中高中涉及卷组操作系统盘与存储空间同盘且分区为LVM管理目录迁移绑定挂载存储空间1有足够容量低低数据复制式迁移系统分区满、Docker/日志等数据占用大重装系统重新分区无重要数据或数据已备份中高设备刚入手尚未存储重要资料我个人更推荐第二种。原因很简单大多数人的核心诉求不是“让系统分区变大”而是“别再让系统分区塞满导致服务挂掉”。目录迁移够用了而且回滚也方便。真要硬着头皮去动LVM卷组反而可能把整个存储空间搞乱。如果你在虚拟化环境比如VMware里跑飞牛想让存储空间分配更合理其实更推荐直接在虚拟机层面把虚拟磁盘扩容再进入系统用分区工具或LVM把多出来的空间分配给系统分区或存储空间这样比在系统内部拆东墙补西墙要省事得多。3. 实操分区空间迁移到存储空间1的完整流程理论部分说得再多不实操都是纸上谈兵。下面进入正题我把这两条路线分别走一遍记录完整的操作步骤和关键命令。你操作之前先记住一句保命箴言不管走哪条路重要数据先备份。别嫌我啰嗦。你接下来要动的是分区表、挂载配置、Docker目录任何一个疏忽都可能导致服务异常或者数据路径错乱。我见过太多人在这一步贪快结果事后花了两天恢复数据。3.1 准备工作备份、查看分区结构、确认文件系统我先按实际操作顺序列一下准备阶段要做的事。第一步打开飞牛系统的SSH终端或者直接在系统设置里开启终端功能。没有SSH权限的话后面所有命令都跑不了。第二步确认分区结构和LVM状态。依次执行以下命令把输出仔细看一遍df -hT lsblk pvscan vgscan lvscan blkid cat /etc/fstab重点看三样东西根分区挂载点/的文件系统类型是ext4还是xfs这决定了扩容时用哪个扩展命令根分区所在逻辑卷或物理分区的名称存储空间1的挂载路径一般可能是/vol1。第三步备份关键配置。至少把/etc/fstab备份一份cp /etc/fstab /etc/fstab.bak第四步查看存储空间1的可用空间df -h /vol1如果存储空间1可用空间充足那目录迁移路线基本稳了。如果存储空间1也满了那就得先往存储空间1里腾空间或者换一块更大的存储盘再说。3.2 实操A用LVM给系统逻辑卷扩容如果你的飞牛系统分区是LVM管理的而且你确认卷组里还有未分配的空间那么扩容根分区的操作其实非常快。我先演示一个把空闲空间全部扩展到根逻辑卷的例子。查看当前的卷组信息vgdisplay输出里会有一个Free PE / Size字段这个就是还能用的空闲容量。注意这里的空闲空间必须是在你的系统卷组比如fnOS_vg内。如果显示为0说明卷组里没有富余空间那就需要先做物理卷扩容或者释放空间。假如卷组里有空闲空间执行扩展lvextend -l 100%FREE /dev/fnOS_vg/root这条命令的意思是把根逻辑卷扩展到占用卷组所有剩余空间。等系统输出“Logical volume root successfully resized”后再扩展文件系统。文件系统类型不同命令不同。ext4用resize2fs /dev/fnOS_vg/rootxfs用xfs_growfs /完成后用df -h /验证一下根分区容量应该已经变大。这里有个非常关键的细节如果你发现系统根分区并不是LVM逻辑卷而是一个普通物理分区比如/dev/sda2那你不能直接lvextend会因为找不到逻辑卷直接报错。这种情况只有两条路可以走要么用fdisk/parted调整物理分区表需要重启且操作风险极大要么干脆放弃扩容路线改用目录迁移方案。我强烈建议普通人选后者别为了一点系统空间去赌分区表操作的成功率。3.3 实操B把Docker/日志目录迁移到存储空间1这一节是本文的绝对重点也是我认为最值得收藏的部分。我以迁移Docker数据目录/var/lib/docker到/vol1/docker为例完整走一遍。先停掉Docker服务systemctl stop docker这一步不能省。如果Docker服务还在运行它可能正在向数据目录写入文件此时直接rsync复制源数据处于活动状态复制出来的结果不等价回写时会出错。停服之后数据目录就静态了复制出来的镜像和容器层才是一份一致性快照。确认服务完全停止systemctl status docker然后创建目标目录并同步数据mkdir -p /vol1/docker rsync -aXS /var/lib/docker/ /vol1/docker/这里的几个参数解释一下-a归档模式保留权限、时间戳、符号链接-X保留扩展属性Docker容器文件里可能涉及-S处理稀疏文件避免复制无用的空洞导致空间浪费。同步过程中我建议你开一个新的SSH窗口用du -sh /vol1/docker随时观察目标目录大小确认数据确实在增长。同步完成后对比一下源和目标的大小du -sh /var/lib/docker du -sh /vol1/docker两者大小应当接近一致。确认无误后把原来的数据目录改名留存作为回滚保险mv /var/lib/docker /var/lib/docker.bak mkdir -p /var/lib/docker接着做绑定挂载mount --bind /vol1/docker /var/lib/docker这条命令执行后系统访问/var/lib/docker时实际读写的已经是/vol1/docker的内容了。但注意这只是临时挂载重启后失效。所以要把挂载规则写入/etc/fstabvim /etc/fstab在文件末尾加一行/vol1/docker /var/lib/docker none bind 0 0然后执行mount -a如果没有报错说明fstab配置没问题。最后启动Docker服务systemctl start docker启动后用docker ps验证容器是否正常还活着。如果之前跑着的容器都正常显示说明数据迁移成功。日志目录的迁移方式一模一样唯一的区别是路径不同。你只需要把/var/lib/docker替换成/var/log目标目录换成/vol1/log然后先执行日志瘦身再迁移也行比如用journalctl --vacuum-size500M先把旧日志清理一波减小迁移体积。3.4 迁移后验证与回收系统空间迁移完Docker目录你可能会发现系统分区还是没降下去多少。这是正常的因为旧的/var/lib/docker.bak还在原地占着空间。确认一切运行正常后再把它清掉rm -rf /var/lib/docker.bak清理之后用df -h /再看一眼系统分区的使用率理论上应该大幅下降。这里有一个我在实践中总结的验证习惯迁移完成后不要只看df -h的数字还要实际检查一下核心服务是否可用。比如飞牛的SMB共享能不能正常访问、应用中心的已安装应用能不能正常启动、Docker容器日志能不能正常写入。因为有些时候文件系统层面看起来没问题但服务因为路径权限或者挂载顺序的问题实际上已经处于半瘫痪状态。再检查一下权限存储空间1如果之前有其他数据目录目录所有权可能和Docker需要的root:root不一致。可以用ls -ld /vol1/docker /var/lib/docker chown -R root:root /vol1/docker确保权限正确后再重启一次Docker服务做最终确认。4. 迁移后的常见问题速查未挂载、起不来、权限异常迁移这件事最怕的不是操作过程出问题而是操作完了一段时间后突然出问题。尤其是“飞牛系统存储空间未挂载”这个关键词几乎隔几天就有人在社区里问。我这里把几类高频问题集中梳理一下方便你对症下药。4.1 存储空间未挂载的排查流程“存储空间未挂载”这个提示一般出现在系统刚启动完或者硬盘插拔之后。常见原因有四种系统异常断电文件系统发生错误导致自动挂载失败硬盘识别顺序发生变化导致挂载规则中的UUID与实际设备对不上手动改过/etc/fstab写入了错误的分区或者绑定路径硬盘或数据线接触不良系统启动时根本没识别到设备。排查思路按顺序来。先看设备是否被识别lsblk blkid如果设备在再用dmesg查看内核日志dmesg | tail -50看看有没有文件系统错误或挂载失败的报错信息。如果是文件系统损坏先卸载对应分区再执行fsck /dev/sdb1注意fsck必须在分区未挂载的状态下执行否则大概率会把文件系统修坏。如果设备不在优先检查物理连接和系统启动时的日志。还有一种常见情况是绑定挂载未生效。比如你迁移Docker目录后重启发现容器全不见了但/vol1/docker里的数据明明还在。这时候先执行mount -a看fstab里的绑定规则能不能补挂上。如果提示找不到挂载点就把/etc/fstab里的那个绑定路径检查一遍确保源目录和目标目录都存在。4.2 迁移后服务启动异常的修复这个问题的触发点很典型Docker数据迁移完成后systemctl start docker时Docker能起来但容器启动时各种报错比如容器有权限问题、文件找不到、目录不存在。八成是两种原因。第一种是rsync复制时没有保留好原有所有权和权限导致容器内用户无法正常访问挂载卷。第二种是源目录在复制之后又有新数据写入你在旧目录上又起过服务然后新旧目录之间出现了数据差异而绑定挂载指向了旧目录的快照。第一种情况的解决办法是核对权限ls -ln /vol1/docker对比原来的目录权限和所有权必要时用chown修正。第二种情况回滚更简单先把绑定挂载去掉恢复旧目录再重新同步一次确保源和目标完全一致后再次绑定。这类问题我在实际维护中遇到过不止一次操作上我建议迁移过程中把Docker服务停的时间尽量延长一点不要急。宁可多停十分钟也不要停在复制到一半就去启动服务。4.3 重启后挂载失效的Fix绑定挂载写进/etc/fstab之后理论上重启会自动加载。但如果你在fstab里写的目标挂载点路径本身就不固定或者挂载点目录在启动时还没创建好就会导致挂载失效。比如你的存储空间1的挂载路径是/vol1如果写入fstab的绑定源路径依赖存储空间1先挂载成功那启动顺序一旦变化绑定就会失败。稳定做法是在fstab里用UUID来指定存储分区的挂载而不是用/dev/sda1这种设备名。设备名在系统启动时可能因为硬盘枚举顺序变化而改变UUID则是分区本身的唯一标识不会变。确认UUIDblkid /dev/sdb1然后修改/etc/fstab中的存储分区挂载行把/dev/sdb1换成实际的UUID。绑定挂载那行保持/vol1/docker /var/lib/docker none bind 0 0这样系统启动时会先按UUID挂载存储空间1再执行绑定挂载顺序就稳定了。我个人在实际操作中还有一个习惯每次改完fstab都先执行mount -a确认没有报错再重启验证一遍。如果重启后挂载没生效立刻在启动后手动执行mount -a输出信息会直接告诉你问题出在哪一行。再分享一个排查小技巧飞牛系统出现挂载异常时很多老手习惯先看/etc/mtab文件它记录了当前所有已生效的挂载点。如果系统启动了但fstab里的绑定行没生效/etc/mtab里不会出现对应的记录这时候问题基本就锁定在fstab配置或启动顺序上。4.4 迁移完成后的空间维护习惯最后额外说一个跟“维护”有关的事。很多人迁移完成之后系统盘空间确实腾出来了但过了几个月又满了。为什么因为只要你还在用Docker、还在用飞牛应用中心装应用日志和缓存就会持续增长。如果不定期清理系统分区迟早再次告急。所以我的建议是迁移完成之后顺手把日志清理策略配一下。把journald的日志上限调低journalctl --vacuum-size300M编辑/etc/systemd/journald.conf把SystemMaxUse改成500M重启journald服务生效systemctl restart systemd-journaldDocker容器产生的日志如果不加限制也会无限增长。在 Docker 配置或容器运行参数里加日志轮转比如限制单容器日志大小logging: driver: json-file options: max-size: 100m max-file: 3这部分虽然不属于“迁移”本身但和你的系统分区能否长治久安直接相关。我的体会是系统分区空间问题从来不是一次迁移就能一劳永逸的。它更像是一种长期的资源管理习惯你把大目录搬走了只是给系统盘腾出了喘息空间后续的日志控制、缓存清理、Docker数据规划才真正决定系统盘会不会再次报警。上面写的这些命令和流程我基本都在飞牛系统上实测过不同版本。尤其是Docker目录迁移那段来回操作过好几轮最顺利的一次从停服到容器恢复只花了不到二十分钟。唯一一次翻车是我当时图省事没有把fstab里的绑定挂载写对结果第二天早上发现系统更新重启之后Docker挂了所有容器报文件不存在。那之后我就养成了强迫症每次改fstab必须执行mount -a必须重启验证。希望这篇内容能帮你少走一次弯路。如果你已经迁移到一半卡住了记住一个原则先把服务停掉再把数据同步完整最后才动挂载配置顺序别乱基本不会出大问题。