开场悬念
先说结论：别急着喷我标题党。
上周我接了个活儿，帮朋友的公司把一台跑了五年、硬盘快塞满的国内云服务器做数据盘扩容，对方运维小哥甩给我一句“用fdisk啊，Linux老传统了”，我当时差点笑出声——这年头谁还在生产环境手动敲fdisk？不都用parted或者图形面板点两下？结果，三天后我灰头土脸地回来写这篇测评，因为fdisk这玩意儿，在国内服务器的网络环境里,还真不是你想的那么简单。
测试环境和工具说明
先交代一下“案发现场”。
服务器：某国内主流云厂商的“经济型”2核4G，系统盘40G，数据盘100G（就是它出问题）。
操作系统：CentOS 7.9，内核3.10。
网络：默认按量计费，带宽峰值50Mbps，实测下行能跑到48Mbps左右。
工具：fdisk（util-linux 2.23.2版本）、dd命令做读写测试、iperf3测带宽延迟、还有最朴素的time计秒。
重点说下网络：这台机子在北京区，我人在上海，延迟基线大概是28ms，别小看这28ms,后面fdisk踩的坑全跟它有关。
实测数据：fdisk的“非典型”挣扎
先跑个fdisk -l，看盘符，一切正常，然后fdisk /dev/vdb，n，p，1，回车，默认起始扇区，按理说10秒完事，但诡异的是，当我输入w保存分区表时，终端卡了整整14秒！
一开始我以为是运气差，结果反复试了三次，每次保存都要卡10到15秒，查了syslog，发现是磁盘I/O在等待内核重读分区表时，触发了一次“软锁定”（soft lockup）警告。
接着用dd实测写入：
- fdisk建好分区后，直接mkfs.ext4，格式化耗时41秒（对比parted同操作只要22秒）。
- 挂载后写1GB文件，fdisk方案平均吞吐89MB/s，波动大，最低掉到61MB/s。
- 而同一块盘，用parted重分区后，写1GB文件稳定在106MB/s，几乎没波动。
这还不算完，我用iperf3测了网络吞吐，发现fdisk分区期间，TCP发送窗口被挤压，带宽从45Mbps掉到12Mbps，持续了大概20秒。
也就是说：fdisk在分区写表时，会短暂阻塞当前设备的I/O队列，进而影响上层网络服务的实时响应，这在本地机房可能无所谓，但国内服务器大多数是云盘（底层走分布式存储）,这个阻塞会被放大到肉眼可见。
竞品对比：fdisk vs parted vs 云控制台
为了不冤枉fdisk，我把同一个操作流程在同样条件下跑了三遍：
都说fdisk是老古董，我在国内服务器上折腾了三天，结果差点被它教做人
- fdisk：兼容性最好，但MBR限制2TB，GPT支持要加参数，分区表保存慢，I/O抖动明显，适合纯内网、无强制网络QoS的老机器。
- parted：原生GPT，分区速度是fdisk的两倍，保存表几乎无延迟，但对新手不友好，误操作没有二次确认，容易把数据盘变砖。
- 云厂商控制台（在线扩容）：不用进系统，后台直接操作，但遇到磁盘有文件系统在挂载时，需要先卸载，否则强制操作可能损坏数据，而且部分厂商不允许对正在写入的盘做在线扩容,必须停机。
讲真，如果只看分区本身，fdisk完全够用，但如果你跑的是Web服务或者数据库，fdisk那个保存时的“卡顿”会让你的监控图表出现一个尖刺，对，就是那种让领导问“刚才是不是有人攻击”的尖刺。
总结推荐：别神化，也别踩死
我的建议很明确：
- 如果你只是给一台不对外服务的国内服务器分个盘，fdisk没问题，老老实实按步骤来，别同时跑高并发任务。
- 如果你要在线扩容且业务不能断，请用parted，或者直接用云控制台的点按钮流程，别逞能。
- 网络延迟高（比如跨城市）时，fdisk的同步操作会让你感觉像在拨号上网。
最后说句公道话：fdisk不是不行，但它是上世纪的设计思路——假设你在机房现场，硬盘是本地盘，网络是千兆内网，可国内服务器大多在“云端”，底层是虚拟化和分布式存储，fdisk那种“写分区表后强制重新读盘”的操作，等于在高速公路上踩急刹车。
我的结论是：老工具不等于烂工具，但用错场景就是你的锅，这次我被fdisk“教做人”，下次你如果非用它，记得先看一眼你的业务能不能容忍那十几秒的“沉默”。
（End）
发表评论