1. 先分清系统盘和数据盘再谈扩容和分区做运维这些年磁盘操作是我处理频率最高的需求之一。尤其是云服务器用户经常会遇到两类问题一是系统盘容量不够业务日志和数据库把40G的盘塞得满满当当二是买了数据盘却不会分区格式化一直放着浪费。这篇文章就把阿里云系统盘扩容、数据盘分区、格式化、挂载、取消挂载整条链路完整梳理一遍所有命令都是我实际跑过的可以直接照着敲。先说清楚一个基础概念系统盘是随实例一起创建、承载操作系统的云盘在Linux里通常是/dev/vda数据盘是额外购买的独立云盘对应/dev/vdb、/dev/vdc等设备名。两者最大的区别在生命周期系统盘和实例强绑定实例释放时默认一起释放数据清零数据盘则是独立资源可以从实例上卸下来重新挂到别的实例上实例重装系统也不会影响数据。正因为这个区别我给自己定了一条铁规矩操作系统和代码放系统盘数据库、日志、用户上传的文件这些核心数据一律放数据盘。这个习惯救过我很多次有次实例系统故障需要重装系统盘格式化重来数据盘原封不动挂回去就恢复了整个过程损失几乎为零。这篇文章适合两类读者一是刚开始用云服务器、对磁盘概念比较模糊的新手跟着操作能少走弯路二是已经跑了一段时间业务、碰到磁盘空间告急需要立刻扩容救火的朋友。下面的内容按操作顺序来先讲系统盘扩容的完整流程再讲数据盘从裸盘到可用空间的三步操作最后覆盖取消挂载和常见故障排查。2. 系统盘扩容控制台操作加底层磁盘调整2.1 控制台操作与准备工作系统盘扩容的第一站不在服务器里而是阿里云控制台。进入ECS实例列表找到目标实例点击“云盘”标签页系统盘那一行右侧会有“扩容”入口。点击后控制台会显示当前容量和你这台实例规格支持扩容到的最大容量确认后按提示操作即可。这里有几个容易踩的坑提前说清楚。第一系统盘扩容有上限不同实例规格的支持范围不一样界面上会明确标注不要想当然觉得可以无限扩。第二扩容方式分为在线扩容和离线扩容部分实例支持不停机在线扩容但如果你跑的数据库或者关键业务对稳定性要求极高我建议还是申请一个维护窗口停服操作最稳妥避免扩容过程中出现意外IO抖动。第三扩容后容量会重新计费费用按新容量档位走控制台会弹出提示别忽略不看。控制台扩容完成后你登录服务器执行lsblk会看到磁盘本身容量已经变大了但分区大小还是老样子。这是因为云盘扩容只是把底层块设备放大了操作系统里的分区表和文件系统还停留在原来的尺寸。打个比方楼房里给你打通了一间新屋子但门还没开东西依然搬不进去。接下来要做的就是“开门”——扩展分区再扩展文件系统。2.2 确认分区表类型登录服务器后先查看当前磁盘现状确保你对环境心里有数lsblk正常情况下比如原本40G的系统盘扩容到80G你会看到/dev/vda的大小已经变成80G但/dev/vda1还是40G剩下的40G处于未分配状态。接着确认分区表类型这一步决定了后续用哪种方式扩展分区fdisk -l /dev/vda输出里如果写着“Disk label type: dos”说明是MBR分区表如果是“gpt”说明是GPT分区表。MBR是老标准2TB容量和4个主分区是它的硬边界GPT是后来的标准突破了2TB限制分区数量也基本不受限。就系统盘扩容这个场景来说MBR和GPT都能操作但命令细节不同看清类型再动手。顺带提醒一句阿里云的Linux系统盘大部分是MBR分区表尤其是默认创建的系统盘。如果你拿到的环境比较新也可能是GPT不要想当然。2.3 扩容核心操作growpart扩展分区现在进入真正的“开门”环节。绝大多数主流Linux发行版都预装了cloud-guest-utils工具包里面带一个growpart命令专门用来把分区扩展到整个磁盘。如果你的系统里没有先安装# Debian / Ubuntu 系 apt-get install cloud-guest-utils # CentOS / RHEL / Alibaba Cloud Linux 系 yum install cloud-utils-growpart安装完成后执行扩展growpart /dev/vda 1注意growpart的语法是“设备名 分区号”两部分中间有空格分区号只写数字。我见过有人写成growpart /dev/vda1直接报错“The partition number is required”看着像低级错误但忙乱的时候真的容易犯。如果你遇到提示说分区无法在线扩展先检查一下有没有可用的块设备变化没生效有时候需要partprobe /dev/vda让内核重新读取分区表。老版本系统如果没有growpart网上流传的办法是用fdisk删除分区再重建把结束扇区改到最大这个做法在数据无损的情况下理论上可行但风险实在太大分区表操作一旦手抖数据就永远找不回来了。我的建议很明确能用growpart就用growpart千万别为了省两步安装命令去玩fdisk删分区。2.4 扩展文件系统resize2fs与xfs_growfs分区扩大以后文件系统还停在旧尺寸必须再走一步。先确认你的根分区是什么文件系统df -hTType列能看到根分区是ext4还是xfs或者其他类型。对应的扩展命令# ext4 系列 resize2fs /dev/vda1 # xfs 系列 xfs_growfs /这两个命令的对应关系千万不要搞混。resize2fs的参数是设备名而且支持在挂载状态下在线执行xfs_growfs的参数则是挂载点比如根路径就是/它不能直接对设备名操作。如果你拿xfs的分区去跑resize2fs会直接报错“Bad magic number in super-block”反过来在ext4上跑xfs_growfs也一样不行。执行完成后用df -h验证一下根分区的容量确认已经变成扩容后的新值这次系统盘扩容就算完整走完了。最后强调一个救命的习惯在growpart之前先在控制台给系统盘打一份快照。磁盘操作不是儿戏尤其生产环境一个小失误可能导致整台实例无法启动快照就是你的后悔药。打快照不需要停实例成本也低却能在关键时刻救回一命这笔投入非常值得。3. 数据盘分区从一块裸盘到可用的空间3.1 新盘挂载后的样子数据盘的分区、格式化、挂载是三个必须按顺序完成的操作缺一个都没法正常使用。就像买了一块新硬盘装上电脑先要分盘再格式化然后才能往里存文件。新购买并挂载的数据盘在Linux系统里默认是一块没有分区的裸盘。用lsblk查看你会看到类似/dev/vdb的设备大小是你购买时的容量但下面没有任何子分区。执行fdisk -l /dev/vdb输出里也没有分区信息这就是标准的裸盘状态。3.2 分区方案怎么规划在开始分区之前先想清楚你要分几个区。绝大部分云服务器场景我的建议都是只分一个区用满整块盘。原因很简单云盘和物理机硬盘不一样它本质是虚拟化出来的存储资源容量扩展非常灵活不像物理机需要提前花心思规划未来几年的容量分布。分多个区不仅增加管理复杂度还容易出现一个区空间爆满、另一个区大量闲置的尴尬情况最后还得靠扩容来回折腾。如果你确实有特殊需求需要多个分区我也建议优先考虑LVM方案而不是用固定分区。LVM的好处是后面空间不够了可以再买一块盘加进卷组把逻辑卷在线扩大完全不影响现有分区和数据。固定分区就没有这个灵活性到时候只能靠缩容腾挪操作复杂得多。3.3 使用fdisk做MBR分区容量小于2TB的数据盘最常用的分区工具是fdisk。执行fdisk /dev/vdb进入交互模式后按顺序操作输入n创建新分区输入p指定主分区类型分区编号默认1直接回车起始扇区默认2048直接回车从盘的开头开始结束扇区默认到磁盘末尾直接回车用满整个空间输入w保存分区表并退出整个过程中除了w必须手动确认其他步骤都可以直接回车吃默认值非常省事。执行完成后用fdisk -l /dev/vdb查看能看到一个/dev/vdb1分区就说明成功了。这里要提醒一个MBR的硬限制一张MBR分区表最多只能有4个主分区如果超过这个数量得用扩展分区加逻辑分区的方案。但对云盘来说基本用不上这套花活一块盘一个主分区用满最干净。3.4 使用parted做GPT分区如果你的数据盘容量超过2TBfdisk就无能为力了MBR的上限就是2TB必须改用parted工具做GPT分区表。交互方式parted /dev/vdc mklabel gpt mkpart primary 0% 100% quit我来解释这三条命令mklabel gpt把分区表格式改成GPTmkpart primary 0% 100%创建一个从0%到100%的主分区用满整个磁盘。如果不想用百分比也可以指定绝对容量比如mkpart primary 0 100GB但我个人偏好0%到100%简单直观不会因为单位换算出问题。parted也支持非交互式操作把命令一次性拼接执行适合在脚本里用parted -s /dev/vdc mklabel gpt mkpart primary ext4 0% 100%执行完后lsblk就能看到新分区了。无论用哪种工具分区完成后如果发现系统没有立刻识别到新分区执行一下partprobe让内核重新读取分区表这个命令专治“明明分区了但看不到”的怪问题。3.5 分区完的检查动作分区创建完成不要急着格式化先做两个检查。第一是确认分区格式正确fdisk -l /dev/vdb看一下Start和End扇区第二是检查分区是否对齐分区起始扇区是2048的整数倍就是对齐的。现在大多数工具默认已经帮你做好了对齐不需要手动干预但养成看一眼的习惯总没有坏处。扇区不对齐会导致IO放大本来一次读写就能完成的工作要多消耗几次性能白白打折。4. 格式化分区、挂载与开机自动挂载4.1 文件系统选型ext4还是xfs分区完成之后进入格式化环节。格式化要做的第一件事是选文件系统类型最常用的是ext4和xfs两种。我的使用经验是如果数据盘主要跑数据库、存大量小文件选ext4更稳妥它的inode机制在处理海量小文件时表现均衡历史上验证充分如果是大数据存储、大文件读写、或者日志这种频繁写入删除的场景xfs表现更好删除大量文件时不会像ext4那样出现明显卡顿RHEL/CentOS系的新系统默认就推荐xfs。不过说句实在话云盘底层IO性能已经很强了两种文件系统在绝大多数日常业务里的差异并不明显你选定一个用顺手了就行不要今天用ext4明天换xfs环境里混用太多种类只会增加后期维护成本。4.2 格式化实操与重要警告选定文件系统后执行格式化# ext4 mkfs.ext4 /dev/vdb1 # xfs mkfs.xfs /dev/vdb1格式化时可以附带一些参数比如ext4默认会预留5%的块给root用户和系统维护对1TB的盘来说就是50G空间有点浪费。我一般会调成1%mkfs.ext4 -m 1 /dev/vdb1这里必须敲响警钟格式化是不可逆操作一旦执行盘上的所有数据会被清空。在跑命令之前先lsblk确认目标设备名没有搞错再检查这块盘上有没有需要保留的数据。千万别拿系统盘当数据盘格式化真出这种事轻则系统崩溃重则数据永远找不回来。我自己就见过同事把vda和vdb搞混的案例一块盘的物理毁灭就是一条命令的事。格式化前反复核对设备名多花十秒钟能避免一辈子的遗憾。4.3 手动挂载格式化完成后创建挂载点并挂载mkdir -p /data mount /dev/vdb1 /data执行完df -h看到/data目录的容量就是数据盘的大小说明挂载成功了。也可以用lsblk查看挂载点会清晰地显示在分区下面。这个阶段属于手动挂载一次性的。服务器一重启挂载关系就会消失你需要再手动执行一次mount才能用。想让数据盘开机自动挂载必须配置fstab见下一步。4.4 fstab配置开机自动挂载的正确姿势先拿到分区的UUIDblkid /dev/vdb1输出类似UUIDxxxxxx TYPEext4。然后编辑/etc/fstab把下面这行追加到文件末尾UUIDxxxxxx /data ext4 defaults 0 2这行的格式需要解释清楚。第一列是UUID我用它而不是/dev/vdb1这类设备名因为云环境里设备名不稳定实例偶尔重启后盘符可能从vdb变成vdc写设备名的话系统会找不到盘。UUID是分区的唯一身份证不会变。第二列是挂载点。第三列是文件系统类型。第四列defaults代表默认挂载选项。第五列0表示不参与备份。第六列2表示开机时在根分区之后检查该文件系统不需要检查就写0。配置完成后强烈建议先验证mount -amount -a会按fstab内容尝试挂载所有还未挂载的文件系统不报错说明配置没问题。进一步可以卸载再重新挂载测试最后在挂载目录里创建文件验证可写umount /data mount -a touch /data/test rm -f /data/test这一步验证不能省。fstab写错最典型的结果是服务器重启时卡住停在“A start job is running for...”的等待状态最后掉进紧急模式屏幕上一堆暗红色的报错。想修复就得通过救援模式去改文件操作复杂心态也容易崩。写fstab的时候多花一分钟验证重启的时候就少受一小时折磨。4.5 目录权限与挂载参数优化挂载完成后根据业务需要调整目录权限。比如你的应用要以某个特定用户身份运行就要把目录owner改过去chown -R admin:admin /data chmod 755 /data如果权限没设置对最常见的结果是nginx、tomcat这类服务跑起来后疯狂报“Permission denied”日志里全是红色错误排查半天才发现是目录归属不对而不是程序本身的问题。对于IO压力大的业务我还会在fstab里加上noatime参数UUIDxxxxxx /data ext4 defaults,noatime 0 2这个参数的作用是关闭文件访问时间的实时更新减少每次读文件时的一次额外写入。对高并发读多写少的场景效果很明显属于性价比很高的优化项。5. 取消挂载、解除绑定与数据盘跨实例迁移5.1 umount卸载的标准流程取消挂载的核心命令是umountumount /data第一个坑就是“target is busy”。只要挂载目录正在被任何进程使用比如某个服务在读写文件或者你当前shell的当前工作目录就在/data下面umount就会报设备忙。所以在卸载之前先执行cd /切出挂载点目录然后卸载。如果还报busy找出占用进程的方式有两种lsof f -- /data fuser -vm /datalsof会列出挂载目录上被打开的文件以及对应的进程fuser -vm则直接输出占用进程的用户和PID。确定占用进程后正常停止服务或者结束进程再执行umount。如果情况紧急服务一时半会儿停不下来数据又不重要可以用强制方式fuser -km /data这条命令会杀掉所有正在使用该挂载点的进程。我一般不推荐上来就强杀但生产环境磁盘打满、需要立刻卸载盘释放空间时这是最快速的手段。强杀之后记得手动确认服务已恢复。5.2 fstab条目清理如果之前配置过开机自动挂载卸载盘之前一定要先处理fstab把对应行注释掉或者删除vim /etc/fstab我习惯用行首加#注释而不是直接删除万一以后还要挂回来搜索出这行改一下就能复用。忘记这一步的后果很严重下次重启系统按照fstab找不到这个分区启动过程会卡住等待可能直接掉进紧急模式。本来只想卸载个数据盘结果整台服务器起不来这就是典型的“小操作大事故”。5.3 控制台卸载数据盘服务器层面的umount做完之后数据盘和实例之间还连着需要到控制台解绑。进入ECS实例的云盘列表找到数据盘点击“更多-卸载”。控制台会先检查云盘状态卸载成功后云盘状态变成“待挂载”这时候它可以作为一块独立的云盘资源挂到其他实例上。还有个细节值得注意如果购买数据盘时勾选了“随实例释放”那么卸载之后这个关联就断了云盘变成一个独立资源以后释放实例时它不会再跟着一起释放。记得去云盘列表确认一下计费方式和释放策略避免产生额外费用或数据保留的意外情况。5.4 数据盘换实例挂载时的注意点数据盘从A实例卸载后挂到B实例有几个容易被忽略的点。第一B实例的操作系统内核要支持数据盘的文件系统比如老版本系统对xfs支持不好挂上去之后分区可能识别不了。第二挂载过去后原来目录的UID和GID可能和新系统里的用户对不上表现为目录明明存在但应用进程没有权限读写需要重新执行chown修正。第三fstab必须在新实例上重新配置设备名、挂载点都要按新环境调整。第四如果盘上是数据库文件要确认数据库版本兼容直接把老版本数据文件挂到新版本数据库上可能打不开。这些点不起眼但生产环境任何一个疏忽都可能演变成事故。做运维就是这样能把不起眼的事情考虑周全才能避免深夜的告警电话。6. 常见问题与排错记录6.1 扩容后看不到新增容量表现原因处理方法lsblk显示磁盘已变大分区没变分区未扩展执行growpart扩展分区growpart成功df容量没变化文件系统未扩展根据文件系统类型执行resize2fs或xfs_growfslsblk显示磁盘还是原大小控制台扩容未生效或实例未重启确认云盘扩容状态必要时重启实例这个类别的问题十有八九落在“忘了扩文件系统”上。growpart处理完分区文件系统的元数据并不会自动感知新空间你必须手动执行resize2fs或者xfs_growfs这一步不能跳过。记住这个三步链路控制台扩容块设备growpart扩分区resize2fs/xfs_growfs扩文件系统。少一步容量就到不了手。6.2 fstab配错导致无法启动最经典的现象是重启后卡在开机过程最后提示“You are in emergency mode”或者类似的错误。原因多半是fstab里的UUID写错、分区不存在、或者文件系统类型写错。修复流程是用救援模式或者控制台VNC登录先把根分区重新挂载为可读写mount -o remount,rw /然后编辑fstab把出错的行注释掉重启验证。这个问题我自己在新手期就踩过后来养成了两条习惯第一fstab里永远用UUID不用设备名第二改完fstab必须执行mount -a验证。这两条习惯直接决定你下次重启会不会多出来一台起不来的机器。6.3 设备忙卸载不掉原因和处理上面已经讲过这里补充一个容易忽略的场景如果挂载点目录是其他进程的工作目录即使没有正在读写文件umount依然会报busy。所以排查的时候除了看服务进程还要检查有没有shell停在这个目录里。用fuser -vm能一眼看清占用情况比瞎猜强得多。6.4 df与lsblk显示的容量对不上df显示的是文件系统视角的容量lsblk显示的是设备视角的容量两者本来就是不同层面的信息。扩容后发现df没变化基本就是漏了resize2fs这一步。另外一个常见诡异情况是df显示磁盘还有很大剩余空间但业务写入时提示“No space left on device”。这时候别盯着容量看了执行df -i查看inode使用率。inode是文件系统里存储文件元数据的索引节点如果建了大量小文件把inode耗尽即使磁盘空间剩余再多也写不进新文件。这个问题在日志类、缓存类应用里特别常见处理办法是清理小文件或者从一开始计划文件系统时预留足够的inode数量。6.5 分区挂载后权限不对数据盘挂载到新实例目录owner的UID/GID对不上就会出现文件在root下可见、但业务进程无法访问的情况。处理方式是新实例上执行chown -R重新设置归属。这个问题不是文件系统坏了纯粹是权限映射的错位别一头扎进去排查半天。6.6 大容量磁盘格式化耗时较长对几个TB的数据盘执行mkfs不会瞬间完成屏幕上可能长时间没有输出。这不是卡死了是正常的格式化过程。ext4格式化大容量盘时在后台初始化inode表期间不要强制中断命令否则可能留下未完成的文件系统后续使用时报错。耐心等它跑完或者用mkfs.ext4 -E lazy_itable_init1跳过部分后台初始化让文件系统在运行期间逐步完成能明显缩短初始格式化时间。7. 个人经验与收尾磁盘相关操作我坚持一个原则每次变更都留档。之前做系统盘扩容和数据盘挂载时我都会把lsblk、df、fdisk的输出前后对比记录下来包括操作时间、执行命令、验证结果。这些随手记的“流水账”在半年后排查问题时价值非常大。磁盘报错时翻出当时的记录往往几秒钟就能定位是哪一步出了问题比在控制台和终端之间反复来回折腾高效得多。另外一个实用习惯是给关键分区做标签备份。无论是系统盘扩容前打快照还是数据盘格式化前做镜像这种“先备份再操作”的流程我已经刻进肌肉记忆了。云盘的快照成本很低但它能保证你犯的任何错误都有回头路。运维这行干久了你会发现大部分事故都不是操作复杂造成的而是省略了该有的防护步骤。快照就是那道最便宜的防线。如果你在扩容、分区、挂载过程中遇到其他奇怪的报错也建议按“控制台状态-设备层-分区层-文件系统层-挂载层”这个顺序逐层排查基本能覆盖90%的磁盘问题。祝你的磁盘空间永远够用扩容永远顺利。 
长河君 · 2026/10/16 7:06:14 · 阅读 1.2k Linux云服务器磁盘扩容与数据盘分区挂载实操指南
1. 先分清系统盘和数据盘再谈扩容和分区做运维这些年磁盘操作是我处理频率最高的需求之一。尤其是云服务器用户经常会遇到两类问题一是系统盘容量不够业务日志和数据库把40G的盘塞得满满当当二是买了数据盘却不会分区格式化一直放着浪费。这篇文章就把阿里云系统盘扩容、数据盘分区、格式化、挂载、取消挂载整条链路完整梳理一遍所有命令都是我实际跑过的可以直接照着敲。先说清楚一个基础概念系统盘是随实例一起创建、承载操作系统的云盘在Linux里通常是/dev/vda数据盘是额外购买的独立云盘对应/dev/vdb、/dev/vdc等设备名。两者最大的区别在生命周期系统盘和实例强绑定实例释放时默认一起释放数据清零数据盘则是独立资源可以从实例上卸下来重新挂到别的实例上实例重装系统也不会影响数据。正因为这个区别我给自己定了一条铁规矩操作系统和代码放系统盘数据库、日志、用户上传的文件这些核心数据一律放数据盘。这个习惯救过我很多次有次实例系统故障需要重装系统盘格式化重来数据盘原封不动挂回去就恢复了整个过程损失几乎为零。这篇文章适合两类读者一是刚开始用云服务器、对磁盘概念比较模糊的新手跟着操作能少走弯路二是已经跑了一段时间业务、碰到磁盘空间告急需要立刻扩容救火的朋友。下面的内容按操作顺序来先讲系统盘扩容的完整流程再讲数据盘从裸盘到可用空间的三步操作最后覆盖取消挂载和常见故障排查。2. 系统盘扩容控制台操作加底层磁盘调整2.1 控制台操作与准备工作系统盘扩容的第一站不在服务器里而是阿里云控制台。进入ECS实例列表找到目标实例点击“云盘”标签页系统盘那一行右侧会有“扩容”入口。点击后控制台会显示当前容量和你这台实例规格支持扩容到的最大容量确认后按提示操作即可。这里有几个容易踩的坑提前说清楚。第一系统盘扩容有上限不同实例规格的支持范围不一样界面上会明确标注不要想当然觉得可以无限扩。第二扩容方式分为在线扩容和离线扩容部分实例支持不停机在线扩容但如果你跑的数据库或者关键业务对稳定性要求极高我建议还是申请一个维护窗口停服操作最稳妥避免扩容过程中出现意外IO抖动。第三扩容后容量会重新计费费用按新容量档位走控制台会弹出提示别忽略不看。控制台扩容完成后你登录服务器执行lsblk会看到磁盘本身容量已经变大了但分区大小还是老样子。这是因为云盘扩容只是把底层块设备放大了操作系统里的分区表和文件系统还停留在原来的尺寸。打个比方楼房里给你打通了一间新屋子但门还没开东西依然搬不进去。接下来要做的就是“开门”——扩展分区再扩展文件系统。2.2 确认分区表类型登录服务器后先查看当前磁盘现状确保你对环境心里有数lsblk正常情况下比如原本40G的系统盘扩容到80G你会看到/dev/vda的大小已经变成80G但/dev/vda1还是40G剩下的40G处于未分配状态。接着确认分区表类型这一步决定了后续用哪种方式扩展分区fdisk -l /dev/vda输出里如果写着“Disk label type: dos”说明是MBR分区表如果是“gpt”说明是GPT分区表。MBR是老标准2TB容量和4个主分区是它的硬边界GPT是后来的标准突破了2TB限制分区数量也基本不受限。就系统盘扩容这个场景来说MBR和GPT都能操作但命令细节不同看清类型再动手。顺带提醒一句阿里云的Linux系统盘大部分是MBR分区表尤其是默认创建的系统盘。如果你拿到的环境比较新也可能是GPT不要想当然。2.3 扩容核心操作growpart扩展分区现在进入真正的“开门”环节。绝大多数主流Linux发行版都预装了cloud-guest-utils工具包里面带一个growpart命令专门用来把分区扩展到整个磁盘。如果你的系统里没有先安装# Debian / Ubuntu 系 apt-get install cloud-guest-utils # CentOS / RHEL / Alibaba Cloud Linux 系 yum install cloud-utils-growpart安装完成后执行扩展growpart /dev/vda 1注意growpart的语法是“设备名 分区号”两部分中间有空格分区号只写数字。我见过有人写成growpart /dev/vda1直接报错“The partition number is required”看着像低级错误但忙乱的时候真的容易犯。如果你遇到提示说分区无法在线扩展先检查一下有没有可用的块设备变化没生效有时候需要partprobe /dev/vda让内核重新读取分区表。老版本系统如果没有growpart网上流传的办法是用fdisk删除分区再重建把结束扇区改到最大这个做法在数据无损的情况下理论上可行但风险实在太大分区表操作一旦手抖数据就永远找不回来了。我的建议很明确能用growpart就用growpart千万别为了省两步安装命令去玩fdisk删分区。2.4 扩展文件系统resize2fs与xfs_growfs分区扩大以后文件系统还停在旧尺寸必须再走一步。先确认你的根分区是什么文件系统df -hTType列能看到根分区是ext4还是xfs或者其他类型。对应的扩展命令# ext4 系列 resize2fs /dev/vda1 # xfs 系列 xfs_growfs /这两个命令的对应关系千万不要搞混。resize2fs的参数是设备名而且支持在挂载状态下在线执行xfs_growfs的参数则是挂载点比如根路径就是/它不能直接对设备名操作。如果你拿xfs的分区去跑resize2fs会直接报错“Bad magic number in super-block”反过来在ext4上跑xfs_growfs也一样不行。执行完成后用df -h验证一下根分区的容量确认已经变成扩容后的新值这次系统盘扩容就算完整走完了。最后强调一个救命的习惯在growpart之前先在控制台给系统盘打一份快照。磁盘操作不是儿戏尤其生产环境一个小失误可能导致整台实例无法启动快照就是你的后悔药。打快照不需要停实例成本也低却能在关键时刻救回一命这笔投入非常值得。3. 数据盘分区从一块裸盘到可用的空间3.1 新盘挂载后的样子数据盘的分区、格式化、挂载是三个必须按顺序完成的操作缺一个都没法正常使用。就像买了一块新硬盘装上电脑先要分盘再格式化然后才能往里存文件。新购买并挂载的数据盘在Linux系统里默认是一块没有分区的裸盘。用lsblk查看你会看到类似/dev/vdb的设备大小是你购买时的容量但下面没有任何子分区。执行fdisk -l /dev/vdb输出里也没有分区信息这就是标准的裸盘状态。3.2 分区方案怎么规划在开始分区之前先想清楚你要分几个区。绝大部分云服务器场景我的建议都是只分一个区用满整块盘。原因很简单云盘和物理机硬盘不一样它本质是虚拟化出来的存储资源容量扩展非常灵活不像物理机需要提前花心思规划未来几年的容量分布。分多个区不仅增加管理复杂度还容易出现一个区空间爆满、另一个区大量闲置的尴尬情况最后还得靠扩容来回折腾。如果你确实有特殊需求需要多个分区我也建议优先考虑LVM方案而不是用固定分区。LVM的好处是后面空间不够了可以再买一块盘加进卷组把逻辑卷在线扩大完全不影响现有分区和数据。固定分区就没有这个灵活性到时候只能靠缩容腾挪操作复杂得多。3.3 使用fdisk做MBR分区容量小于2TB的数据盘最常用的分区工具是fdisk。执行fdisk /dev/vdb进入交互模式后按顺序操作输入n创建新分区输入p指定主分区类型分区编号默认1直接回车起始扇区默认2048直接回车从盘的开头开始结束扇区默认到磁盘末尾直接回车用满整个空间输入w保存分区表并退出整个过程中除了w必须手动确认其他步骤都可以直接回车吃默认值非常省事。执行完成后用fdisk -l /dev/vdb查看能看到一个/dev/vdb1分区就说明成功了。这里要提醒一个MBR的硬限制一张MBR分区表最多只能有4个主分区如果超过这个数量得用扩展分区加逻辑分区的方案。但对云盘来说基本用不上这套花活一块盘一个主分区用满最干净。3.4 使用parted做GPT分区如果你的数据盘容量超过2TBfdisk就无能为力了MBR的上限就是2TB必须改用parted工具做GPT分区表。交互方式parted /dev/vdc mklabel gpt mkpart primary 0% 100% quit我来解释这三条命令mklabel gpt把分区表格式改成GPTmkpart primary 0% 100%创建一个从0%到100%的主分区用满整个磁盘。如果不想用百分比也可以指定绝对容量比如mkpart primary 0 100GB但我个人偏好0%到100%简单直观不会因为单位换算出问题。parted也支持非交互式操作把命令一次性拼接执行适合在脚本里用parted -s /dev/vdc mklabel gpt mkpart primary ext4 0% 100%执行完后lsblk就能看到新分区了。无论用哪种工具分区完成后如果发现系统没有立刻识别到新分区执行一下partprobe让内核重新读取分区表这个命令专治“明明分区了但看不到”的怪问题。3.5 分区完的检查动作分区创建完成不要急着格式化先做两个检查。第一是确认分区格式正确fdisk -l /dev/vdb看一下Start和End扇区第二是检查分区是否对齐分区起始扇区是2048的整数倍就是对齐的。现在大多数工具默认已经帮你做好了对齐不需要手动干预但养成看一眼的习惯总没有坏处。扇区不对齐会导致IO放大本来一次读写就能完成的工作要多消耗几次性能白白打折。4. 格式化分区、挂载与开机自动挂载4.1 文件系统选型ext4还是xfs分区完成之后进入格式化环节。格式化要做的第一件事是选文件系统类型最常用的是ext4和xfs两种。我的使用经验是如果数据盘主要跑数据库、存大量小文件选ext4更稳妥它的inode机制在处理海量小文件时表现均衡历史上验证充分如果是大数据存储、大文件读写、或者日志这种频繁写入删除的场景xfs表现更好删除大量文件时不会像ext4那样出现明显卡顿RHEL/CentOS系的新系统默认就推荐xfs。不过说句实在话云盘底层IO性能已经很强了两种文件系统在绝大多数日常业务里的差异并不明显你选定一个用顺手了就行不要今天用ext4明天换xfs环境里混用太多种类只会增加后期维护成本。4.2 格式化实操与重要警告选定文件系统后执行格式化# ext4 mkfs.ext4 /dev/vdb1 # xfs mkfs.xfs /dev/vdb1格式化时可以附带一些参数比如ext4默认会预留5%的块给root用户和系统维护对1TB的盘来说就是50G空间有点浪费。我一般会调成1%mkfs.ext4 -m 1 /dev/vdb1这里必须敲响警钟格式化是不可逆操作一旦执行盘上的所有数据会被清空。在跑命令之前先lsblk确认目标设备名没有搞错再检查这块盘上有没有需要保留的数据。千万别拿系统盘当数据盘格式化真出这种事轻则系统崩溃重则数据永远找不回来。我自己就见过同事把vda和vdb搞混的案例一块盘的物理毁灭就是一条命令的事。格式化前反复核对设备名多花十秒钟能避免一辈子的遗憾。4.3 手动挂载格式化完成后创建挂载点并挂载mkdir -p /data mount /dev/vdb1 /data执行完df -h看到/data目录的容量就是数据盘的大小说明挂载成功了。也可以用lsblk查看挂载点会清晰地显示在分区下面。这个阶段属于手动挂载一次性的。服务器一重启挂载关系就会消失你需要再手动执行一次mount才能用。想让数据盘开机自动挂载必须配置fstab见下一步。4.4 fstab配置开机自动挂载的正确姿势先拿到分区的UUIDblkid /dev/vdb1输出类似UUIDxxxxxx TYPEext4。然后编辑/etc/fstab把下面这行追加到文件末尾UUIDxxxxxx /data ext4 defaults 0 2这行的格式需要解释清楚。第一列是UUID我用它而不是/dev/vdb1这类设备名因为云环境里设备名不稳定实例偶尔重启后盘符可能从vdb变成vdc写设备名的话系统会找不到盘。UUID是分区的唯一身份证不会变。第二列是挂载点。第三列是文件系统类型。第四列defaults代表默认挂载选项。第五列0表示不参与备份。第六列2表示开机时在根分区之后检查该文件系统不需要检查就写0。配置完成后强烈建议先验证mount -amount -a会按fstab内容尝试挂载所有还未挂载的文件系统不报错说明配置没问题。进一步可以卸载再重新挂载测试最后在挂载目录里创建文件验证可写umount /data mount -a touch /data/test rm -f /data/test这一步验证不能省。fstab写错最典型的结果是服务器重启时卡住停在“A start job is running for...”的等待状态最后掉进紧急模式屏幕上一堆暗红色的报错。想修复就得通过救援模式去改文件操作复杂心态也容易崩。写fstab的时候多花一分钟验证重启的时候就少受一小时折磨。4.5 目录权限与挂载参数优化挂载完成后根据业务需要调整目录权限。比如你的应用要以某个特定用户身份运行就要把目录owner改过去chown -R admin:admin /data chmod 755 /data如果权限没设置对最常见的结果是nginx、tomcat这类服务跑起来后疯狂报“Permission denied”日志里全是红色错误排查半天才发现是目录归属不对而不是程序本身的问题。对于IO压力大的业务我还会在fstab里加上noatime参数UUIDxxxxxx /data ext4 defaults,noatime 0 2这个参数的作用是关闭文件访问时间的实时更新减少每次读文件时的一次额外写入。对高并发读多写少的场景效果很明显属于性价比很高的优化项。5. 取消挂载、解除绑定与数据盘跨实例迁移5.1 umount卸载的标准流程取消挂载的核心命令是umountumount /data第一个坑就是“target is busy”。只要挂载目录正在被任何进程使用比如某个服务在读写文件或者你当前shell的当前工作目录就在/data下面umount就会报设备忙。所以在卸载之前先执行cd /切出挂载点目录然后卸载。如果还报busy找出占用进程的方式有两种lsof f -- /data fuser -vm /datalsof会列出挂载目录上被打开的文件以及对应的进程fuser -vm则直接输出占用进程的用户和PID。确定占用进程后正常停止服务或者结束进程再执行umount。如果情况紧急服务一时半会儿停不下来数据又不重要可以用强制方式fuser -km /data这条命令会杀掉所有正在使用该挂载点的进程。我一般不推荐上来就强杀但生产环境磁盘打满、需要立刻卸载盘释放空间时这是最快速的手段。强杀之后记得手动确认服务已恢复。5.2 fstab条目清理如果之前配置过开机自动挂载卸载盘之前一定要先处理fstab把对应行注释掉或者删除vim /etc/fstab我习惯用行首加#注释而不是直接删除万一以后还要挂回来搜索出这行改一下就能复用。忘记这一步的后果很严重下次重启系统按照fstab找不到这个分区启动过程会卡住等待可能直接掉进紧急模式。本来只想卸载个数据盘结果整台服务器起不来这就是典型的“小操作大事故”。5.3 控制台卸载数据盘服务器层面的umount做完之后数据盘和实例之间还连着需要到控制台解绑。进入ECS实例的云盘列表找到数据盘点击“更多-卸载”。控制台会先检查云盘状态卸载成功后云盘状态变成“待挂载”这时候它可以作为一块独立的云盘资源挂到其他实例上。还有个细节值得注意如果购买数据盘时勾选了“随实例释放”那么卸载之后这个关联就断了云盘变成一个独立资源以后释放实例时它不会再跟着一起释放。记得去云盘列表确认一下计费方式和释放策略避免产生额外费用或数据保留的意外情况。5.4 数据盘换实例挂载时的注意点数据盘从A实例卸载后挂到B实例有几个容易被忽略的点。第一B实例的操作系统内核要支持数据盘的文件系统比如老版本系统对xfs支持不好挂上去之后分区可能识别不了。第二挂载过去后原来目录的UID和GID可能和新系统里的用户对不上表现为目录明明存在但应用进程没有权限读写需要重新执行chown修正。第三fstab必须在新实例上重新配置设备名、挂载点都要按新环境调整。第四如果盘上是数据库文件要确认数据库版本兼容直接把老版本数据文件挂到新版本数据库上可能打不开。这些点不起眼但生产环境任何一个疏忽都可能演变成事故。做运维就是这样能把不起眼的事情考虑周全才能避免深夜的告警电话。6. 常见问题与排错记录6.1 扩容后看不到新增容量表现原因处理方法lsblk显示磁盘已变大分区没变分区未扩展执行growpart扩展分区growpart成功df容量没变化文件系统未扩展根据文件系统类型执行resize2fs或xfs_growfslsblk显示磁盘还是原大小控制台扩容未生效或实例未重启确认云盘扩容状态必要时重启实例这个类别的问题十有八九落在“忘了扩文件系统”上。growpart处理完分区文件系统的元数据并不会自动感知新空间你必须手动执行resize2fs或者xfs_growfs这一步不能跳过。记住这个三步链路控制台扩容块设备growpart扩分区resize2fs/xfs_growfs扩文件系统。少一步容量就到不了手。6.2 fstab配错导致无法启动最经典的现象是重启后卡在开机过程最后提示“You are in emergency mode”或者类似的错误。原因多半是fstab里的UUID写错、分区不存在、或者文件系统类型写错。修复流程是用救援模式或者控制台VNC登录先把根分区重新挂载为可读写mount -o remount,rw /然后编辑fstab把出错的行注释掉重启验证。这个问题我自己在新手期就踩过后来养成了两条习惯第一fstab里永远用UUID不用设备名第二改完fstab必须执行mount -a验证。这两条习惯直接决定你下次重启会不会多出来一台起不来的机器。6.3 设备忙卸载不掉原因和处理上面已经讲过这里补充一个容易忽略的场景如果挂载点目录是其他进程的工作目录即使没有正在读写文件umount依然会报busy。所以排查的时候除了看服务进程还要检查有没有shell停在这个目录里。用fuser -vm能一眼看清占用情况比瞎猜强得多。6.4 df与lsblk显示的容量对不上df显示的是文件系统视角的容量lsblk显示的是设备视角的容量两者本来就是不同层面的信息。扩容后发现df没变化基本就是漏了resize2fs这一步。另外一个常见诡异情况是df显示磁盘还有很大剩余空间但业务写入时提示“No space left on device”。这时候别盯着容量看了执行df -i查看inode使用率。inode是文件系统里存储文件元数据的索引节点如果建了大量小文件把inode耗尽即使磁盘空间剩余再多也写不进新文件。这个问题在日志类、缓存类应用里特别常见处理办法是清理小文件或者从一开始计划文件系统时预留足够的inode数量。6.5 分区挂载后权限不对数据盘挂载到新实例目录owner的UID/GID对不上就会出现文件在root下可见、但业务进程无法访问的情况。处理方式是新实例上执行chown -R重新设置归属。这个问题不是文件系统坏了纯粹是权限映射的错位别一头扎进去排查半天。6.6 大容量磁盘格式化耗时较长对几个TB的数据盘执行mkfs不会瞬间完成屏幕上可能长时间没有输出。这不是卡死了是正常的格式化过程。ext4格式化大容量盘时在后台初始化inode表期间不要强制中断命令否则可能留下未完成的文件系统后续使用时报错。耐心等它跑完或者用mkfs.ext4 -E lazy_itable_init1跳过部分后台初始化让文件系统在运行期间逐步完成能明显缩短初始格式化时间。7. 个人经验与收尾磁盘相关操作我坚持一个原则每次变更都留档。之前做系统盘扩容和数据盘挂载时我都会把lsblk、df、fdisk的输出前后对比记录下来包括操作时间、执行命令、验证结果。这些随手记的“流水账”在半年后排查问题时价值非常大。磁盘报错时翻出当时的记录往往几秒钟就能定位是哪一步出了问题比在控制台和终端之间反复来回折腾高效得多。另外一个实用习惯是给关键分区做标签备份。无论是系统盘扩容前打快照还是数据盘格式化前做镜像这种“先备份再操作”的流程我已经刻进肌肉记忆了。云盘的快照成本很低但它能保证你犯的任何错误都有回头路。运维这行干久了你会发现大部分事故都不是操作复杂造成的而是省略了该有的防护步骤。快照就是那道最便宜的防线。如果你在扩容、分区、挂载过程中遇到其他奇怪的报错也建议按“控制台状态-设备层-分区层-文件系统层-挂载层”这个顺序逐层排查基本能覆盖90%的磁盘问题。祝你的磁盘空间永远够用扩容永远顺利。