老机器救星！用parted给国内服务器无痛分区，数据差点没了？实测保命指南

开场悬念

兄弟们，先问个扎心的问题：你手里那台跑了两三年的国内云服务器，磁盘空间是不是快见底了？前天有个粉丝私信我，说他的数据盘买了1TB，结果分区分小了，想扩区又怕数据全没，问我有没有“无损扩容”的野路子。

我直接甩给他一个命令：parted，他当场懵了：“这不是Linux自带的那个老古董吗？能用它搞扩容？” 嘿嘿，今天我就拿三台不同机房、不同厂商的国内服务器，实测一把parted到底能不能扛住“在线扩容+数据安全”这活儿，别急，先卖个关子：有一台机器，扩容过程中我差点以为它“凉了”……往下看。

测试环境和工具说明

先报背景，我手头有三台机器，都是国内主流机房（屏蔽具体厂商，免得说广告）：

工具就是系统自带的parted，版本3.3，全程不关机、不卸载分区，直接对在线磁盘操作，测试工具用dd写随机数据测吞吐，ping和iperf3测延迟带宽，对了，全程我开着dmesg监控内核日志,怕真出幺蛾子。

实测数据：延迟/带宽/吞吐，别急着激动

先跑个基准,不然扩容后性能掉了谁负责？

延迟：三台机器内网互ping，平均都在0.3ms左右，扩容前后没变化,正常。
带宽：用iperf3打满内网，机器A能在890Mbps稳定跑，机器B在920Mbps，机器C差点——只有600Mbps（可能是轻量机型宿主机限速），扩容后复测，没有掉速。
吞吐：重点来了，用dd if=/dev/zero of=/data/test bs=1M count=2048写入2GB文件：

机器	扩容前写速	扩容后写速	变化
A (ext4)	155 MB/s	149 MB/s	-4%
B (xfs)	171 MB/s	168 MB/s	-2%
C (LVM)	112 MB/s	95 MB/s	-15%

看到没？前两台基本无感，机器C直接掉了15%，这锅parted不背——是LVM层在扩容后的PV扩展时产生了额外IO开销，所以别迷信“工具万能”,分区类型决定下限。

竞品对比：parted vs fdisk vs 云控制台扩容

有人问：“云厂商控制台不是能直接扩吗？干嘛用parted？” 我三台机器都试了：

云控制台：只支持“磁盘扩容”后自动识别，但前提是你分区表得先用parted改好，否则控制台扩了容量，文件系统还是老样子,等于白忙活。
fdisk：对GPT分区支持稀烂，动不动就“WARNING: GPT table”，还得删了重建，数据有风险，parted直接resizepart,一条命令完事。
parted实操对比效果：机器A和B，用parted /dev/vdb resizepart 1 100%后，接着resize2fs或xfs_growfs，全程2分钟，无报错，机器C的LVM麻烦点，还得pvresize + lvextend，但parted把分区表改完,后面就顺了。

致命细节：机器C在parted resizepart时，我忘了指定---pretend-input-tty（非交互模式），结果分区表写入一半，系统卡住了3秒——那一刻我心脏骤停，好在parted自己回滚了，没丢数据。忠告：线上千万别不加-s参数就执行！

总结推荐

结论很直白：

如果你的数据盘是ext4或xfs，且不是LVM → 直接上parted，用-s静默模式，按“实测”看,性能损耗可以忽略不计。
如果是LVM → 能用parted，但扩容后吞吐下降10%-15%，建议后续改用lvm原生命令（pvresize/lvextend）而不是依赖parted改分区表。
千万别用fdisk搞GPT盘，它连自己生成的UUID都认不全,数据出事儿别喊冤。

最后说点实在话：parted是个老工具，但它“简单、透明、不受云厂商绑架”，云控制台让你点鼠标，其实底层还是调用了它，与其被图形界面忽悠，不如自己敲命令心里有数。至于那台差点“凉了”的机器C，现在跑得稳如老狗，只是写速稍慢——可它便宜啊,还要啥自行车？

下回你们遇到磁盘不够，先别急着提工单，拿parted试试，万一成了，省下的钱给自己加个鸡腿,它不香吗？