【服务器】针对Centos7: /dev/sda3扩容

引言：当服务器亮起红灯——"No space left on device"

对于任何一位 Linux 运维工程师或后端开发者来说，最不愿意看到的报错提示之一，莫过于 No space left on device（设备上没有足够的空间）。

前段日子，博主在自己的 CentOS 7 服务器上进行批量的 RPM 依赖包下载和环境编译。由于编译产生的临时文件和 RPM 包数量极其庞大，系统突然停止响应，各种服务相继罢工。排查日志后，终端冷酷地抛出了报错：/dev/sda3 does not have enough space。

经过 df -h 命令确认，发现 /dev/sda3 这个核心数据分区的空间使用率已经飙升至惊人的 98%！系统濒临崩溃，数据库无法写入，连最基本的 Tab 键命令补全都会报错。

面对这种绝境，常规的“清理日志、删除旧文件”只能是扬汤止沸，无法解决根本的业务增长需求。唯一的破局之道就是——为硬盘进行物理扩容，并无损扩展现有的文件系统。 博主遂就这次惊心动魄的扩容实战进行一次完整的记录与深度复盘，希望能帮到遇到同样问题的你。

一、问题缘由

前段日子，博主在服务器上进行rpm包下载-由于rpm数量较多，导致出现报错-/dev/sda3 does not have enough space

经过确认查看/dev/sda3文件大小，确实是已经使用98%--得进行扩容来解决次问题-博主遂就此问题进行一个记录！

扩容前的拦路虎：VMware 虚拟机的快照机制

在物理机上扩容需要插硬盘，而在 VMware 等虚拟化平台上，我们只需要动动鼠标即可完成。但是，很多新手在这里会立刻踩到第一个大坑：虚拟机硬盘扩展选项是灰色的，根本无法点击！

为什么无法扩容？
VMware 的底层机制决定了，如果你的虚拟机当前存在任何“快照（Snapshot）”，虚拟磁盘文件的结构就会被锁定在特定的差异链（Delta Link）中。为了保护快照数据的完整性，VMware 会强制禁止用户对基础磁盘的容量进行修改。

解决方案：

1. 备份重要数据： 扩容是一项高危操作，请务必先将服务器内的核心代码、数据库（如 MySQL/Redis）通过 FTP 或 SCP 导出到本地物理机。
2. 清理快照： 关停虚拟机（Power Off）。进入 VMware 的“快照管理器”，将该虚拟机下的所有历史快照全部删除（Delete All）。
3. 执行扩容： 快照清理完毕后，右键虚拟机 -> 设置 -> 硬盘 -> 扩展（Expand）。此时按钮已经恢复可用状态，填入你期望的最终硬盘大小（例如从 50G 扩展到 100G），点击应用。

至此，我们在物理层面（Hypervisor 层）已经把硬盘撑大了，但这就像是你换了一个更大的空书柜，里面的书（分区）并没有自动变多。接下来，我们需要进入 Linux 系统内部，对分区和文件系统进行“动刀”。

二、解决方案

VMware虚拟机硬盘空间不足时，想扩展空间，若是VMware虚拟机硬盘扩展是灰色的，无法完成扩展操作

首先要进入虚拟机快照管理器，删除快照，删除后就可以扩容

1.使用df -hh 查看具体哪个目录占满硬盘容量--笔者这里是sda3

2.fdisk /dev/sda 进行分区操作
3.选择 d,删除分区，这里我是删除3，按照机器显示的内容根据实际情况输入要删除的分区
4.输入d -再输入3-再输入P
5.删除3分区后（这里删除分区不会删除原分区3里边的数据），再次重新输入n后，再输入p,接下来一直默认即可创建新分区3
6.输入w,保存退出

7.输入 partprobe /dev/sda 通知下操纵系统分区表已经发生了变化
8.xfs_growfs /dev/sda3--扩容成功
9.使用df -h 再次查看扩容是否成功

三、 核心原理解析：为什么可以“先删除再重建”？

在进行实操前，我们需要明确一个 Linux 磁盘管理的硬核机制。很多初学者听到“删除分区”会感到非常害怕，担心数据丢失。

实际上，Linux 的 fdisk 别名分区表工具，修改的仅仅是硬盘开头的分区表索引（即记录了分区的起始和结束位置），并不会真正去抹除底层数据块（Data Blocks）上的内容。

只要我们确保重新建立的新分区

四、 系统内部排查：精准定位爆满的磁盘空间

重新启动虚拟机，使用 SSH 登录系统。

1. 宏观查看磁盘使用情况
首先，使用命令 df -Th 查看当前各个挂载点的容量情况。df 命令不仅能看容量，带上 -T 还能看文件系统类型。
你会明显看到 / 根目录（或者特定的数据目录）对应的设备 /dev/sda3 使用率报警。

2. 微观查看块设备结构
接着，执行 lsblk 命令。这个命令极其重要，它能清晰地展示出物理硬盘（sda）和下面各个分区（sda1, sda2, sda3）的树状关系。
此时你会发现一个神奇的现象：顶层的 sda 容量已经变成了你扩容后的 100G，但是下面的 sda3 依然还是原来的大小。这就印证了我们前面的比喻——大房间建好了，但旧隔断还没拆。

五、 刀尖上的起舞：fdisk 重建分区的核心实操

这是整个扩容过程中最让人心跳加速的一步。我们需要使用 fdisk 工具，先将旧的 sda3 分区删除，然后再原位新建一个更大的 sda3 分区。

请严格按照以下步骤在终端中操作：

1. 进入分区工具： 输入 fdisk /dev/sda，进入针对第一块物理硬盘的交互式操作界面。

2. 删除旧分区 (d)： * 输入 d（delete a partition），按下回车。

   • 系统会询问你要删除哪个分区号。根据我们的排查，输入 3（代表删除 /dev/sda3），回车确认。

3. 创建新分区 (n)：

   • 紧接着，输入 n（add a new partition）来新建分区。
   • 分区类型选择 p（primary 主分区）。
   • 分区号输入 3（必须与刚才删除的分区号保持绝对一致）。

4. 确定柱面起止位置（至关重要）：

   • 系统会提示你输入 First sector（起始扇区）。这里极其关键，必须直接按回车，使用系统推荐的默认值！ 这保证了新分区的起点和老分区完全重合。
   • 接着提示 Last sector（结束扇区）。这也是我们扩容的目的，直接按回车，使用默认的最大值，将所有新增加的物理空间全部囊括进来。

5. 拒绝清除签名 (N)：

   • 如果系统提示 Partition #3 contains a xfs signature. Do you want to remove the signature? [Y]es/[N]o:。这里一定要输入 N 并回车！ 绝不能清除文件系统签名，否则数据将灰飞烟灭。

6. 保存并退出 (w)：

   • 确认所有步骤无误后，输入 p 可以预览一下新的分区表。
   • 最后输入 w（write table to disk and exit），将新的分区表写入硬盘并退出。

六、 核心原理深度剖析：为什么“先删再建”不会丢失数据？

很多初学者看到上面的“输入 d 删除分区”时，手都在发抖，生怕一按回车，服务器里的代码和数据库就灰飞烟灭了。

为了克服这种恐惧，我们需要深入理解 Linux 磁盘管理的硬核机制。

分区表 ≠ 真实数据
你可以把一块硬盘想象成一本厚厚的字典。字典的最前面几页是“目录”（Partition Table 分区表），后面几千页才是真正的“字词解释”（Data Blocks 数据块）。

当我们在 fdisk 里输入 d 删除分区时，Linux 内核所做的事情，仅仅是用橡皮擦把字典“目录”里的那一排字给擦掉了，它根本没有去触碰后面几千页的实际数据。 你的文件、代码、图片，依然原封不动地躺在硬盘的磁道上。

起始扇区的魔法
当我们紧接着输入 n 重新创建分区时，只要我们严格保证新分区的“起始扇区 (First sector)”与旧分区完全一模一样，操作系统就能重新通过这把钥匙，精准地找回原来的数据。而我们将“结束扇区 (Last sector)”推到了硬盘的最末端，就等于是在旧目录的基础上，把这一个章节的范围扩大了，从而包含了我们从 VMware 扩容进来的全新空白空间。

只要你不去执行 mkfs（格式化操作），你的数据就是绝对安全的。这就是无损扩容的底层原理！

七、 刷新内核与文件系统扩容

分区表虽然在硬盘上改好了，但在内存中运行的 Linux 内核还没反应过来，文件系统也不知道自己变大了。我们需要完成最后两步的“刷新”工作。

1. 通知内核重载分区表
执行命令：
partprobe /dev/sda
这个命令的作用是强行通知 Linux 内核读取最新的硬盘分区表信息。如果没有报错，说明内核已经识别到了扩容后的 /dev/sda3。如果你遇到 Device or resource busy 的警告，说明某些服务正紧紧咬住磁盘不放，此时你只需要简单粗暴地执行 reboot 重启服务器即可。

2. 扩展文件系统边界 (xfs_growfs)
内核知道分区变大了，但运行在分区上的 XFS 文件系统还守着原来的旧边界。
针对 CentOS 7 默认的 XFS 文件系统，我们使用以下命令将其拉伸至填满整个新分区：
xfs_growfs /dev/sda3

(补充提示：如果你的系统是 CentOS 6 或者使用的是 ext4 文件系统，该命令需替换为 resize2fs /dev/sda3)

看到终端迅速刷出一片数据块更新的信息后，扩容操作就彻底宣告成功了！

3. 最终验证
再次输入最熟悉的命令：
df -h
此时你会惊喜地发现，/dev/sda3 的总容量已经变成了扩容后的大小，使用率从濒危的 98% 骤降到了一个健康、安全的阈值。警报解除！

八、 总结与日常运维避坑建议

通过以上的操作，我们不仅完美解决了 No space left on device 的危机，更深入理解了 Linux 磁盘与分区底层的运作逻辑。在实战运维中，想要彻底告别磁盘焦虑，除了掌握扩容技术，博主还强烈建议大家养成以下好习惯：

1. 定期清理 Yum 缓存： 经常安装软件会导致 /var/cache/yum 极度膨胀，定期执行 yum clean all 能释放大量空间。
2. 限制系统日志大小： Systemd 的 journal 日志如果不加限制，甚至能吃掉几十个 G。通过配置 journalctl --vacuum-time=7d 可以强制只保留最近 7 天的日志。
3. 慎用 Docker 默认路径： 如果服务器跑了大量容器，默认的 /var/lib/docker 会迅速抽干根目录空间。建议在条件允许的情况下，将 Docker 的数据目录软链接到独立挂载的数据盘中。

系统运维是一场持久战，每一次敲击命令前的深思熟虑，都是对生产环境最基础的敬畏。希望这篇文章能成为你在服务器运维道路上的一本硬核避坑指南！