1. 先摸清家底df、du 和日志目录三件套体检在社区里看到不少银河麒麟V10的求助帖一上来就是“根分区满了”“磁盘空间不足导致软件装不上”但真要动手扩容我建议先忍住别急着敲 fdisk。因为V10默认安装时桌面版和服务器版的磁盘布局差异挺大有人根分区走的是LVM有人直接是一整块裸设备分区还有人挂载了单独数据盘却没有自动挂载。如果不先搞清楚当前的分区和文件系统状态后面所有操作都可能走错方向。1.1 用 df -hT 看清挂载点真实占用第一步永远是看整体盘子命令不用多花哨df -hT这个输出里最关键的不是“还剩多少”而是两列文件系统类型和挂载点。V10桌面版常见的根文件系统是 ext4 或 xfs服务器版如果安装时选了自动分区多半会走 LVM 逻辑卷。看到/dev/mapper/vg00-lv_root这种路径说明是 LVM看到/dev/sda2这种路径说明是裸设备分区。我个人还习惯加一条df -i看 inode 占用。很多人只盯着空间忽略了小文件太多把 inode 耗尽的情况。如果 inode 使用率到 100%磁盘明明还有几十G系统照样报“空间不足”这种情况扩容文件系统没用得先清小文件。1.2 用 du 揪出大目录和大文件知道哪些挂载点满了之后就该定位“空间到底被谁吃掉了”。在 V10 上我一般直接从根目录往下扫du -h --max-depth1 / 2/dev/null | sort -rh | head -20这条命令会把根目录下第一层目录按占用大小从高到低列出来。如果某个目录比如/home或者/var特别大再往下一层扫du -h --max-depth1 /home 2/dev/null | sort -rh | head -20要找“某个大文件具体在哪”配合 find 更直接find / -xdev -type f -size 1G -exec ls -lh {} \; 2/dev/null-xdev的作用是只在当前文件系统内找不跨越挂载点避免重复扫描也省时间。这一步在 V10 上我强烈建议做一遍因为很多求助帖里所谓的“空间不够”其实是备份文件、虚拟机镜像、日志文件堆在某个角落没被发现。把大文件找出来有些可以直接清理掉根本不需要扩容。1.3 日志目录往往是第一个“隐性炸弹”排查时重点关注两个目录/var/log和/var/lib。尤其 V10 桌面版如果长时间不重启journald 日志可能已经占掉好几个G但 df 结果里它被算在根分区里不细分根本看不出来。快速体检du -sh /var/log journalctl --disk-usage ls -lh /var/log/*.log 2/dev/null如果/var/log占用超过 1G那这个扩容操作先等等直接清理日志可能就能腾出 30% 以上的空间后面我会单独用一整节讲清理方法。这里先记住结论空间体检三件套是 df、du、journalctl缺一个都可能漏掉真正的修复路径。2. LVM 卷组在线扩容V10 服务器上最省事的路径如果你的 V10 是服务器版或者安装时选择了 LVM 自动分区那恭喜扩容路径基本是最平滑的。LVM 最大的好处就是可以把多块物理硬盘合并成一个卷组再按需划给逻辑卷整个过程不用停机也不用碰分区表。2.1 确认系统是否走了 LVM在动手前先看三样东西lsblk pvs vgs lvslsblk看整体设备树输出里如果看到vg00、vg_xxx之类的卷组名说明走了 LVM。pvs列出物理卷vgs列出卷组lvs列出逻辑卷。我习惯一次性把这三个都敲了因为它们分别对应“物理盘”“卷组”“逻辑卷”三个层级的现状。举个实际例子假设 V10 服务器上卷组名是vg00根逻辑卷是/dev/mapper/vg00-lv_root现在要加一块 500G 的新盘/dev/sdb进去。操作链路是物理卷 - 卷组 - 逻辑卷 - 文件系统一层层往上哪一层缺空间就扩哪一层。2.2 新盘加入卷组并划给逻辑卷先把新盘初始化为物理卷pvcreate /dev/sdb然后把这块物理卷加入卷组vgextend vg00 /dev/sdb这时候卷组的空闲空间Free PE应该已经变大可以用vgs确认。接着把空间划给根逻辑卷。划多少有两种思路一种是明确指定大小lvextend -L 200G /dev/vg00/lv_root另一种是干脆把卷组剩余空间全部给某个逻辑卷lvextend -l 100%FREE /dev/vg00/lv_root我在生产环境更推荐第一种留一部分空间在卷组里以备不时之需比如以后想给/home单独建逻辑卷时还有余量。直接用光所有空间虽然省事但后续再想调整就少了一张底牌。2.3 ext4 和 xfs 的文件系统拉伸区别逻辑卷扩大了文件系统这一步千万不能漏而且 ext4 和 xfs 的命令不一样。先看文件系统类型df -hT /dev/mapper/vg00-lv_root如果是 ext4resize2fs /dev/mapper/vg00-lv_root如果是 xfsxfs_growfs /注意我这里写的参数不同ext4 传给 resize2fs 的是设备路径xfs 传给 xfs_growfs 的既可以是挂载点也可以是设备路径。还有一个关键差异ext4 既可以扩大也可以缩小但 xfs 只支持扩大不支持缩小。这个差异决定了你在给 xfs 逻辑卷分配空间时要想清楚宁可少分一点也别分多了以后收不回来。V10 默认内核 4.19对这两种文件系统的在线扩容支持都已经很成熟。但如果你自己换过内核比如从 4.19 换到其他版本我建议扩容操作优先用系统自带内核启动一次再做避免文件系统工具版本和内核特性不匹配把元数据搞出问题。这个坑我见过不止一次。3. 新增独立硬盘挂载目录不碰根分区也能解围有些场景根分区本身就小比如 V10 桌面版安装时只给了根目录 50G系统装完就用了大半。这种时候硬扩根分区风险高、收益低不如加一块新硬盘整个挂载到/home或/data这类目录下把用户数据搬过去根分区的压力一下子就解了。3.1 分区格式化以及 UUID 的确认新盘接入后先确认设备名lsblk比如新盘是/dev/sdb整盘直接用一个分区或者用 parted 做 GPT 分区表parted /dev/sdb mklabel gpt parted /dev/sdb mkpart primary 1MiB 100%FREE分区完成后格式化mkfs.ext4 /dev/sdb1这里文件系统选 ext4 还是 xfs 没强制要求但如果你这块盘以后可能需要在 Windows 和 V10 之间来回拷贝数据也可以考虑格式化成 NTFS 或者 exFAT。不过从稳定性和权限管理角度V10 本机挂载我还是默认推荐 ext4。格式化后一定要记下 UUID后面写 fstab 要用blkid /dev/sdb1把输出里的UUIDxxxx-xxxx-xxxx复制出来这是挂载时的最佳标识。用 UUID 而不是设备名可以避免以后设备顺序变化导致挂载错乱。3.2 fstab 自动挂载的正确写法手动挂载很简单mkdir -p /data mount /dev/sdb1 /data但只挂这一次重启后就没了。要开机自动挂载编辑/etc/fstabvim /etc/fstab追加一行UUIDxxxx-xxxx-xxxx /data ext4 defaults 0 2这行各字段的含义依次是设备标识、挂载点、文件系统类型、挂载参数、是否 dump 备份、fsck 检查顺序。最后一个字段根分区一般是 1其他分区我习惯写 2表示开机时在根之后做文件系统检查。写完别急着重启先验证mount -a df -hTmount -a会按照 fstab 重新挂载所有条目如果配置有误这里就会报错。很多人在 fstab 里写错设备名或 UUID重启后系统卡在维护模式就是因为少了这一步验证。3.3 数据迁移与目录软链处理新盘挂上去之后真正的目标是迁移数据。比如想给/home腾空间思路是这样先把/home下的数据完整拷贝到新盘对应目录然后空掉原目录再把新盘挂到/home上。拷贝时注意保留权限和属主rsync -av /home/ /data/home/rsync比cp更适合这种迁移因为可以断点续传而且只拷贝差异部分。如果没有 rsync也可以装一个yum install -y rsync数据拷完后验证一下文件数量对不对得上diff -r /home /data/home确认无差异再改挂载点。一个更灵活的做法是不动原目录直接用软链把访问路径指过去mv /home /home_old ln -s /data/home /home这种方式对系统透明任何访问/home的路径都会自动落到新硬盘上。但要注意如果/home原本就是独立分区需要先改 fstab 或者卸载后才能 mv否则会报“设备忙”。我自己的习惯是能不用软链就不用软链直接把分区挂到真实目录上少一层间接就少一类问题。4. 裸设备根分区扩容桌面版最容易翻车的操作V10 桌面版安装时很多时候根分区并不是 LVM而是直接建在/dev/sda2这类裸设备分区上文件系统是 ext4 或 xfs。这种布局想扩大根分区就不得不动分区表而分区表操作是整个扩容过程中最危险的一步稍有不慎系统直接起不来。4.1 判断根分区到底在不在 LVM 里先确认lsblk如果设备树里只有sda1、sda2没有任何vg或lv字样再执行pvdisplay没有输出就说明没走 LVM根分区是裸设备分区。这种情况下想扩容思路就是把根分区这个“容器”扩大然后让文件系统跟着扩大。听起来简单但分区表不是随便改的。4.2 growpart 安全扩大分区最安全的做法是用growpart这个工具它能在不删除分区的情况下扩大分区容量前提是分区后面要有空闲空间。V10 上安装yum install -y cloud-utils-growpart使用方式growpart /dev/sda 2这表示把/dev/sda的第 2 个分区扩大到磁盘末尾剩余空间。执行后分区就变大了但文件系统还没感知到。如果是 ext4resize2fs /dev/sda2如果是 xfsxfs_growfs /这里必须强调growpart能成功的前提是扩展分区的后面没有其他分区占用空间。如果sda2后面还有sda3之类的分区就得先处理后面那个分区或者直接放弃这种方案。很多人的 V10 桌面版分区布局是这样sda1是 EFI 分区sda2是根分区后面可能没有任何分区了这是最理想的情况。4.3 分区重建方式的兜底步骤与止损点如果手头没有 growpart或者系统架构特殊必须手动重建分区那就只能把根分区删了再建。具体流程是fdisk /dev/sda进入交互界面后输入p查看分区表记录根分区的起始扇区Start 字段和分区类型Id 字段这个必须记准。然后d删除根分区再n新建分区起始扇区要和原来完全一致结束扇区默认拉到最大值。最后w写盘。整个过程只改变分区结束位置不动起始位置所以文件系统元数据理论上还在原地。但风险在于如果中途断电、扇区记错、分区类型没保留系统就可能起不来。写盘前按两次p仔细核对这是我血泪换来的习惯。分区建完后执行partprobe让内核重新读取分区表再resize2fs拉伸文件系统。如果你对起始扇区没有十足把握我建议直接放弃手动分区重建改用 growpart或者干脆备份数据重装系统。这个止损点很重要。很多求助帖里用户卡在“扩容失败进不去系统”就是因为分区表被搞乱了。扩容不成功可以再来系统起不来损失就大了。5. 清理日志腾空间扩容之外的顺手活很多人在 V10 上报“磁盘满”的时候其实是被日志蛀空了空间。扩容前顺手清理日志既可以缓解眼前压力也可以让扩出来的空间更耐用的毕竟日志不清过段时间照样爆。5.1 journald 日志的快速瘦身使用 systemd 的系统journald 日志默认会占用最多 10% 的磁盘空间听起来不多但在根分区只有 50G 的 V10 桌面版上5G 日志说占就占。先看现状journalctl --disk-usage如果占用很大直接压缩journalctl --vacuum-size200M这条命令会把日志总量压到 200M 以内。也可以按时间清journalctl --vacuum-time7d只保留最近 7 天日志。想从根源上限制改/etc/systemd/journald.confSystemMaxUse500M然后重启服务生效systemctl restart systemd-journald有个细节V10 上如果/var/log/journal这个目录存在日志会持久化保存重启后依然存在。如果你希望日志尽量少占空间可以检查并清理这个目录du -sh /var/log/journal5.2 /var/log 下的传统日志与 logrotate 配置除了 journald/var/log下还有一批传统日志文件比如 dmesg、messages、syslog以及各种应用的日志。找大文件find /var/log -type f -size 100M -exec ls -lh {} \; 2/dev/null找到后可以直接清空但我不建议直接rm因为进程可能还持有文件句柄删掉后空间不会释放反而会把句柄越拉越多。正确做法是echo /var/log/messages把文件内容清空进程继续往里面写也没有问题。长期来看让 logrotate 帮你管理。检查/etc/logrotate.conf和/etc/logrotate.d/目录确认 V10 自带的应用日志是否都纳入了轮转。如果有某个服务日志没有被管理就手动在/etc/logrotate.d/下加一个配置。比如针对某大日志/var/log/xxx.log { daily rotate 7 compress missingok notifempty }表示每天轮转一次保留 7 份轮转后压缩。5.3 清理前必须养成的备份习惯清理日志这件事虽然看起来人畜无害但也要讲究分寸。我在 V10 上清理之前至少会做两件事第一journalctl --since today快速扫一眼最近日志确认没有异常报错需要保留第二如果这台机器要交给审计日志删除要谨慎尽量只压缩历史日志而不是彻底清空。养成这个习惯之后你会发现“磁盘空间不足”这个问题的出现频率会低很多。日志清理和扩容是两件事但真正解决问题的思路应该是先节流再扩容。6. 远程操作与回滚保障V10 扩容的兜底细节扩容操作经常不是在机房现场做的而是通过 SSH 或者远程桌面连到 V10 上操作。这时候最怕的不是命令输错而是命令执行到一半网络断了Local 端和远程端全都失去响应。我跟别人分享扩容经验时一定会单独强调远程扩容必须做会话保障和回滚保障。6.1 用 tmux 保证远程会话不中断无论是 resize2fs 还是 xfs_growfs文件系统拉伸都需要时间分区越大、文件越多等待越久。如果在普通 SSH 会话里执行断网瞬间命令就没了最坏的情况是文件系统元数据写到一半系统直接处于不一致状态。解决办法是用 tmux 包一层会话yum install -y tmux tmux new -s resize然后在 tmux 窗口里执行扩容命令。即使 SSH 断开tmux 会话还在后台继续跑。重新连上后tmux attach -t resize就能回到原来的会话看到执行结果。这个习惯在 V10 远程扩容时几乎是刚需我甚至会在 lvextend 之前就先开好 tmux。如果是 Windows 远程 V10 桌面环境用远程桌面客户端操作也一样先把 tmux 开起来再执行命令避免远程桌面窗口卡死或者被误关闭导致操作中断。6.2 扩容前必须做的分区表与 fstab 备份我在任何分区、扩容操作前都会留下“后悔药”V10 上具体是三份sfdisk -d /dev/sda /root/sda_partitions.bak cp /etc/fstab /root/fstab.bak df -hT /root/df_before.txt第一份备份分区表以后想恢复原状可以直接sfdisk /dev/sda /root/sda_partitions.bak。第二份备份挂载配置一旦改坏了能恢复。第三份记录操作前的空间状态操作完成后对比就知道空间增加是否正确。这三个文件我建议放在/root下因为根分区一般不会被卸载哪怕系统进不去用 live 环境也能在这个路径找到它们。6.3 操作完成后的基础校验扩容完成后别急着走做一轮基础校验df -hT确认目标文件系统大小已经更新。然后试着重启一次系统确认分区表、fstab、文件系统检查都能正常通过。很多人在线扩容时一切正常重启后才发现 fstab 里引用了不存在的设备或者分区表有隐患。而重启这一步能提前把这类问题暴露出来代价远小于事后补救。V10 上有几个常见的小坑可以提前预防fstab 里写设备名而不是 UUID导致设备顺序变化后挂载错位分区重建后忘了执行partprobe系统仍然用旧分区表xfs 文件系统拉伸后无法缩回空间分配没有留余量。这些都是我在实际求助帖里反复看到的故障点写下来也是提醒自己扩容这件事快不得每一步确认好了再走下一步。从我自己的经验看V10 扩容这件事真正复杂的不是“执行命令”而是“判断该走哪条路”。LVM 就扩卷组和逻辑卷裸设备分区就慎用 growpart数据盘不足就新增挂载日志膨胀就先清理。先把系统看透再决定动哪一层比一上来就敲 fdisk 靠谱得多。我现在的习惯是任何远程扩容操作之前先花五分钟做体检、开 tmux、备份分区表这三件事做完后面基本不会出大乱子。