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-depth=1 / 2>/dev/null | sort -rh | head -20

这条命令会把根目录下第一层目录按占用大小从高到低列出来。如果某个目录比如/home或者/var特别大，再往下一层扫：

du -h --max-depth=1 /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 lvs

lsblk看整体设备树，输出里如果看到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

如果是 ext4：

resize2fs /dev/mapper/vg00-lv_root

如果是 xfs：

xfs_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

把输出里的UUID="xxxx-xxxx-xxxx"复制出来，这是挂载时的最佳标识。用 UUID 而不是设备名，可以避免以后设备顺序变化导致挂载错乱。

3.2 fstab 自动挂载的正确写法

手动挂载很简单：

mkdir -p /data mount /dev/sdb1 /data

但只挂这一次，重启后就没了。要开机自动挂载，编辑/etc/fstab：

vim /etc/fstab

追加一行：

UUID=xxxx-xxxx-xxxx /data ext4 defaults 0 2

这行各字段的含义依次是：设备标识、挂载点、文件系统类型、挂载参数、是否 dump 备份、fsck 检查顺序。最后一个字段，根分区一般是 1，其他分区我习惯写 2，表示开机时在根之后做文件系统检查。

写完别急着重启，先验证：

mount -a df -hT

mount -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 个分区扩大到磁盘末尾剩余空间。执行后分区就变大了，但文件系统还没感知到。如果是 ext4：

resize2fs /dev/sda2

如果是 xfs：

xfs_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-size=200M

这条命令会把日志总量压到 200M 以内。也可以按时间清：

journalctl --vacuum-time=7d

只保留最近 7 天日志。想从根源上限制，改/etc/systemd/journald.conf：

SystemMaxUse=500M

然后重启服务生效：

systemctl restart systemd-journald

有个细节：V10 上如果/var/log/journal这个目录存在，日志会持久化保存，重启后依然存在。如果你希望日志尽量少占空间，可以检查并清理这个目录：

du -sh /var/log/journal

5.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、备份分区表，这三件事做完，后面基本不会出大乱子。