前几天有位同事问我Linux 上给一块新盘做分区到底该用 fdisk 还是 partedMBR 和 GPT 又该怎么选。这问题看着基础但真不是一两句话能说清的。我整理了一下自己这些年在 Linux 硬盘分区管理上的操作笔记和踩坑记录把它写成一篇完整内容。不管你是第一次给服务器加数据盘还是已经在用 LVM 但想系统梳理一遍这篇内容应该都能给你一些能直接上手的参考。1. 分区表选型先看容量和引导方式再决定 MBR 还是 GPT1.1 MBR 的 2TB 上限和四个主分区限制到底卡在哪MBR 分区表在磁盘最开始的地方放了一个主引导记录其中用于描述分区的区域很小。具体来说这块区域共 64 字节每条分区记录占用 16 字节所以最多只能存 4 条主分区记录。想要更多分区就得拿一条主分区的记录换成扩展分区再在扩展分区里套逻辑分区。这个设计在当年够用但到了一块盘要分很多用途的时候管理成本就上来了。容量方面的限制更明显MBR 用 32 位字段表示扇区地址按传统 512 字节扇区计算最大寻址范围是 2^32 × 512 字节算下来就是 2TB 左右。超过这个容量要么放弃要么就得用 GPT。这里有个容易混淆的点网上经常说GPT 必须配 UEFI实际上在纯数据盘场景下BIOS 模式的机器也可以使用 GPT 分区表只要引导程序能识别 GPT。但如果是系统盘且沿用传统 BIOS 引导很多老主板对 GPT 引导支持不好这时选 MBR 反而省心。我在实际环境里的判断标准很简单数据盘超过 2TB 或者需要超过 4 个分区选 GPT系统盘在老平台 BIOS 引导下优先 MBR 方案新平台 UEFI 引导直接 GPT。这个原则基本不会错。1.2 GPT 的备份分区表是它最容易被忽略的优点GPT 不是简单把地址位宽放大它还改变了整个分区表的组织方式。主分区表之外GPT 在磁盘尾部有一份备份分区表。如果主分区表被意外破坏很多恢复工具可以靠备份分区表把它救回来。这个特性在生产环境的容错价值非常高比我一开始想象的重要得多。另外 GPT 对每个分区可以保存一个类型 GUID和分区名称。比如 Linux filesystem、Linux LVM、EFI System设备管理直观很多。Linux 下可以用lsblk -o PARTTYPENAME直接看到某个分区的用途描述排障时非常方便。这个信息在 MBR 下只有分区类型 ID不熟悉的人很难记住 83 是 Linux、8e 是 LVM、82 是 swap 这类编号。等到你真的要给一块盘做多用途规划时GPT 这点特性带来的省心是实实在在的。不过也要提醒一句GPT 新增字段的便利性依赖操作系统支持。在极老的发行版或嵌入式系统里GPT 支持可能不完整。做兼容性评估时可以先在旧环境里用工具查一下我遇到过部分旧工具把 GPT 盘识别成unknown的情况这种情况下只能先做工具升级或换用兼容方案。1.3 查看当前分区表类型的三个命令开始动盘之前第一件事永远是确认当前状态。我一般按顺序执行lsblk -o NAME,SIZE,TYPE,PARTTYPENAME,MOUNTPOINT这个命令能列出所有块设备、大小、类型、分区类型名称和挂载点。第二板斧fdisk -l /dev/sda输出中的 Disklabel type 字段会显示 gpt 或 dos前者是 GPT后者是 MBR。第三板斧parted /dev/sda printprint 输出中有一行Partition Table: gpt或msdos。这三条命令看下来设备在不在、分区表是什么、分区边界在哪、挂载点有没有被占用基本一目了然。我自己遇到状态和预期不符时会先停一下不急着操作。分区工具是破坏性工具输错一个字母可能就删掉整块盘的分区表。先确认、再动手这是硬盘分区管理里最便宜也最有效的自我保护。2. 三种分区工具怎么配合使用fdisk、parted、gdisk 各自擅长什么2.1 fdisk 是经典但别把它当成万能工具fdisk 几乎在所有 Linux 发行版里都有对新手的友好度也高因为它每一步都有交互提示。很多教程里的g 创建 GPT 分区表、n 创建分区、w 写入退出说的就是它。但 fdisk 有一个短板它面向传统交互式场景设计对自动化脚本不算友好。虽然新版支持 echo 命令管道但分区创建这类高风险动作我一般不建议在没验收的情况下盲写脚本。另一个短板是旧版本里 fdisk 对 GPT 的支持曾经不完整遇到大容量 GPT 盘可能无法正确处理。现在大多数发行版的 fdisk 是 util-linux 版本情况好很多但这依然是排查问题时要留意的历史包袱。还有个小坑是参数含义在 fdisk 交互界面里输入 g 是新建 GPT 分区表输入 o 是新建 MBR 分区表。两个字母很近手一快就按错。按错之后如果还没 w 写入危害不大但如果你紧接着 w旧分区表就没了。实测下来我都是先敲 p 确认当前布局再敲 g 或 o尽量减少误操作概率。2.2 parted 在对齐检查和脚本化操作上更可靠parted 同时支持交互和非交互模式。它的优势在于直接支持 GPT、能指定百分比范围、还内置 align-check 对齐检查。在对齐敏感的场景下这一项功能很实用。非交互模式可以直接用parted /dev/sdb --script mklabel gpt parted /dev/sdb --script mkpart primary 0% 100%这样把创建标签和分区合并进脚本是可行的。但有两点要提醒。第一parted 的 rm 命令同样是非交互且立即生效的脚本里一旦参数错误可能秒删分区。所以我用 parted 脚本时一定会先加一层保护先 print 确认设备路径再在脚本里用变量承接设备名避免手滑把 /dev/sda 写成 /dev/sdb。第二primary这个关键字在 GPT 下其实没有历史含义只是写上去不报错。在 MBR 下它才区分主分区和逻辑分区。很多人会疑惑这里写 primary 到底对不对实际上 GPT 表中这个值不影响结果放心用。gdisk 则是专门的 GPT 工具。它的功能定位更像GPT 世界的 fdisk交互风格几乎是 fdisk 的镜像但所有操作都围绕 GPT 数据结构展开。它还提供 MBR 转 GPT 的模拟功能用于只读预览。我用gdisk -l /dev/sdc列出信息不做修改是做迁移评估时的安全操作。2.3 一个完整的数据盘分区模板可以直接照着用假设新加了一块 4TB 数据盘设备名 /dev/sdb目标是把整块盘做成一个 GPT 分区文件系统用 XFS挂载到 /data。第一步确认盘符lsblk确认 /dev/sdb 确实是新加的空白盘而且没有已挂载的文件系统。如果不小心把系统盘当成数据盘来分区后面就是灾难。第二步初始化分区表并创建分区parted /dev/sdb --script mklabel gpt parted /dev/sdb --script mkpart primary 0% 100%第三步刷新内核分区表partprobe /dev/sdb第四步确认分区出现lsblk /dev/sdb这时应该能看到 /dev/sdb1。第五步格式化mkfs.xfs /dev/sdb1第六步临时挂载验证mkdir -p /data mount /dev/sdb1 /data第七步写入 fstab 实现开机自动挂载。这一步我不建议直接写设备名建议用 UUID后面会详细说。blkid /dev/sdb1得到 UUID 后在 /etc/fstab 加一行然后执行mount -a没有报错说明配置没问题。整个过程看起来不复杂但每一步都有对应的确认点。第一次操作的人最容易漏掉 mkfs因为分区创建后看起来已经有设备节点了以为可以直接挂载。实际上没有文件系统的分区挂载时会报错我在帮人排查时见过很多次。2.4 工具选型小结什么时候用哪个简单归纳一下日常交互式分区用 fdisk需要脚本化创建用 parted专门管理 GPT 分区表或做 GPT 相关转换评估用 gdisk已有分区表损坏需要扫描恢复用 testdisk。工具不在多而在知道每个工具适合什么场景。硬盘分区管理的大多数问题其实不是工具不够用而是对分区表和设备的理解不够深。3. 分区表只是地图文件系统和挂载才是日常接触最多的部分3.1 文件系统选型XFS、ext4、Btrfs 怎么挑分区表建完之后接下来要决定分区上用哪种文件系统。对这个选择我很少只看某个基准测试的分数更看重的是这个文件系统在我要用的发行版里是不是默认支持、扩容工具是否成熟、资料和排障经验多不多。ext4 的优势是普及率极高从入门教程到企业文档处处都是它的影子。CentOS/Rocky/Alma 系以前默认 ext4后来默认改成 XFS原因之一是 XFS 在超大文件、超大分区场景下表现更稳定。在 Debian/Ubuntu 系里ext4 依然是默认。如果你的需求跑在通用服务器上ext4 几乎不会出大问题。XFS 的优势是大容量高吞吐但有一个知名限制不支持缩容。这个问题我在第 4 部分还会强调。Btrfs 则集成了快照、子卷、压缩、校验和写时复制功能丰富但随之而来的是运维复杂度。如果团队对 Btrfs 不熟悉我倾向于在需要稳定和简单时避开它而在需要快照链路自动化时再考虑。如果做一张对比表大概是这个感受文件系统适合场景主要限制扩容支持缩容支持ext4通用默认场景资料多、稳定超大文件/海量小文件不是最优支持 resize2fs支持缩容但风险高XFS大容量、高吞吐数据盘不支持缩容支持 xfs_growfs不支持Btrfs需要快照、子卷、压缩复杂度高支持支持但复杂文件系统一旦选好并写入大量数据后再想换就是一次数据迁移成本很高所以初始选型值得多花十分钟想清楚。3.2 为什么生产环境挂载要用 UUID 而不是 /dev/sdb1很多新手写 fstab 时直接写 /dev/sdb1在只有一块盘时不会出问题但多盘环境或重启后盘符乱序时就会遇到明明配置没错设备却挂载到了别处的诡异现象。这是因为内核在枚举设备时并不保证盘符顺序固定不变。UUID 是文件系统创建时生成的全局唯一标识重启不会变也不会因为插槽顺序改变。查看方式blkidblkid 的输出里UUID后面的一长串是文件系统 UUIDPARTUUID是分区本身的标识。fstab 挂载文件系统时用文件系统的 UUID某些场景比如引导相关才用 PARTUUID这两个概念别混淆。LABEL 也可以用来挂载优点是短、直观、可读性好缺点是必须保证全部磁盘上 LABEL 唯一。我见过两台机器共用一块移动盘LABEL 一样导致挂载点错乱的情况。所以建议固定盘用 UUID移动盘或备份盘给一个清晰 LABEL 也可以但每次插入前先查一遍。3.3 fstab 字段里最容易出事的两个位置fstab 每一行结构是设备、挂载点、文件系统类型、挂载选项、dump、fsck。日常最容易出问题的一是挂载选项二是 fsck 字段。挂载选项里defaults 是一组默认选项的组合包含 rw、suid、dev、exec、auto、nouser、async。如果设备是外接且可能不存在建议在选项里加 nofail这样开机时设备缺失不会导致系统进入紧急模式等待。否则你可能经历一次开机卡在 busybox 提示符的惊悚体验。fsck 字段0 表示不检查1 表示优先检查2 表示在 1 之后检查。根文件系统通常填 1其他本地文件系统填 2不需要开机检查的填 0。别全都填 1那会导致启动时对所有分区做完整检查慢得离谱。改完 fstab 后记得执行 mount -a 验证。mount -a 会按 fstab 尝试挂载所有条目如果语法或路径有错它会立刻报出来。这一步能救回无数个改完重启起不来的周末。4. 扩容、缩容与 LVM真正的管理动作在这里4.1 一次在线扩容的完整链路硬盘分区管理不只是建一个新分区这么简单。过了几个月数据盘满了这时你就得真正管理它了。最常见的场景是虚拟机磁盘扩容虚拟化平台把虚拟磁盘从 100GB 扩到了 200GB客户机里的 /dev/vda 也变成了 200GB但分区 /dev/vda1 和文件系统还是旧的 100GB。此时扩容分三个阶段。第一阶段确认内核能识别到新容量。如果 /dev/vda 显示还是旧大小可能需要重启或者用命令重读分区表。虚拟化环境里最省心的办法是重启一次或者确认设备没有挂载活动时让内核重新扫描。在新内核下大多能自动识别但遇到旧内核就老实重启。第二阶段扩展分区。针对 /dev/vda1其实就是把分区表里这个分区的结束位置往后移让分区覆盖完整块盘。工具是 growpartgrowpart /dev/vda 1注意 growpart 的参数中间有个空格前面是磁盘设备后面是分区号。不少人在第一遍会把 /dev/vda 和 1 连写成 /dev/vda1这个写法不对。如果你的发行版没装 growpart可以用 parted 的 resizepart 做同样的事但会要求你输入新的结束位置需要先查旧结束扇区稍微麻烦一点。第三阶段扩展文件系统。ext4 用 resize2fsXFS 用 xfs_growfsresize2fs /dev/vda1或者xfs_growfs /很多教程把二、三阶段混在一起说实际操作中必须分开先分区表后文件系统。分区表扩展不到位文件系统扩展就会失败或只扩了一部分。我在第一次操作时就栽在区域还没扩就调 resize2fs上文件系统报错后才知道顺序的问题。4.2 缩容始终是高风险动作如果说扩容是常规操作缩容就是分区管理的高危区。ext4 支持缩容XFS 明确不支持Btrfs 支持但复杂。即使工具支持缩容过程一旦中断比如断电或内核崩溃文件系统就可能处于不一致状态恢复成本非常高。我的原则很简单生产环境能不做缩容就不做。如果确实需要缩容正确姿势是先备份再在维护窗口内操作操作时尽量卸载分区避免读写并发。更稳妥的方案是迁移式缩容把数据复制到新设备删除旧分区重建小分区再拷回数据。虽然耗时多但每一步都可回退。有人会问为什么 XFS 不支持缩容还这么多人用因为很多场景根本不需要缩容数据只会越积越多而扩容工具几乎所有文件系统都支持。选择文件系统时把是否需要缩容作为一项评估指标比事后想办法更靠谱。4.3 LVM 是长期主义的分区管理方案如果说直接操作 GPT 分区表是硬分区那 LVM 就是软分区。LVM 把物理分区变成 PV多个 PV 组成 VG再从 VG 里划分 LV。这样分区边界不再被物理设备的位置约束扩容缩容都灵活得多还能跨盘。我处理数据盘的标准做法是先用 parted 把整盘建成一个 LVM 类型分区然后依次pvcreate /dev/sdb1 vgcreate vg_data /dev/sdb1 lvcreate -L 500G -n lv_data vg_data mkfs.xfs /dev/vg_data/lv_data后面数据卷不够用在 VG 有余量时lvextend -L 50G /dev/vg_data/lv_data xfs_growfs /data如果是 ext4 就变成lvextend -L 50G /dev/vg_data/lv_data resize2fs /dev/vg_data/lv_data这个流程比直接改 GPT 分区表简单而且几乎不影响运行。LVM 也有自己的快照能力虽然性能和可靠性不如专门的存储方案但在临时备份、升级测试场景里够用。LVM 的缺点也很明显多了一层抽象灾难恢复时路径更多排查逻辑链更长如果遇到 PV 损坏修复难度比普通分区大。所以我也只在有多盘、容量规划不确定或需要频繁扩容的场景里使用 LVM而不是无脑全盘 LVM。分区管理的核心是权衡不是炫技。5. 踩坑复盘分区管理最容易翻车的地方5.1 误删分区后我做了什么把它救回来前面说了很多不要做什么这里讲一个真实经历。一次在测试机上重做分区时我原本要删 /dev/sdc1结果在 fdisk 交互里敲了 d、回车、回车没有仔细核对分区号就确认了删掉的其实是当时还挂载着文件系统的 /dev/sdc2。一瞬间 lsblk 里分区消失数据看似全没了。我当时第一反应不是马上重新分区写数据而是立即停止对这个设备的任何写入操作。然后用 dd 把整块盘做镜像到一块备用盘再在镜像上用 testdisk 扫描分区表。testdisk 找回了原 GPT 分区表的大部分参数重新写入后数据完整恢复。这个经历给我最大的教训是分区工具默认不会阻止你犯低级错误所有确认都是你自己承担责任。恢复工具再强都不如事前多看一眼分区号。另外任何重要数据在分区操作前都应该有独立备份没有备份就做分区级别的破坏性操作等于拿数据赌博。5.2 分区对齐随机读写性能差距可以从能忍变成不能忍现代磁盘物理扇区几乎都是 4K闪存存储甚至还有更大的写入单位。分区起始位置如果没有按物理扇区对齐一次读改写请求可能要多读写好几个扇区在顺序读写里影响不大但在随机小 IO 场景下性能下降能明显感知。分区对齐的检查方法parted /dev/sdb align-check optimal 1输出 aligned 表示第 1 个分区对齐。如果没对齐在新部署的系统里最省事的处理是删除分区并用默认参数重新创建如果数据已经写入那就只能评估是否值得迁移。好在现代 fdisk、parted 的默认值都考虑了对齐只要你不是手动指定了一个奇怪的起始扇区数基本不会踩坑。我踩过的一个具体坑是这样的有块旧盘从别人手里接手起始扇区写的是 34没有对齐顺序读没问题一到数据库随机读写就慢得异常。后来把数据迁出来重建分区性能才恢复。所以拿到迁移盘时除了看容量和文件系统最好也顺手查一下对齐状态。5.3 swap 分区的新旧思路swap 这个话题看起来和分区管理关系不大其实联系很深。老一代 Linux 教程里手动分区时都会划一块 swap 分区因为它比 swap 文件更底层不依赖文件系统。但现在内存容量普遍大了很多swap 的使用场景集中在内存突发峰值兜底和避免 OOM 杀进程而不是给一台 512MB 内存的老机器续命。相比之下swap 文件更灵活创建、调整都不需要动分区表dd if/dev/zero of/swapfile bs1M count8192 chmod 600 /swapfile mkswap /swapfile swapon /swapfile如果已经规划了 LVM把 swap 做成一个 LV 也很方便还能随时扩容。除非目标机器有非常特殊的引导或早期启动要求我倾向于不再单独建原始 swap 分区。这个变化背后是内存硬件的大幅升级也反映了分区管理决策必须跟着实际负载走。5.4 分区管理里最值得养成的三个习惯复盘这些年的操作记录真正让我少翻车的是三个习惯。第一任何操作之前先跑 lsblk、parted print、blkid 三连确认状态。第二破坏性操作之前先想清楚能不能重建有没有备份、配置能不能回滚。第三动 fstab 之后一定 mount -a 验证动分区表之后一定 partprobe 或 lsblk 确认。这三点看起来笨但每一个都是真金白银换来的。如果你刚开始学 Linux 硬盘分区管理我建议先从一台不重要的虚拟机开始练手创建分区、格式化、挂载、扩容走完一遍再碰生产环境。分区表错误大多不会毁掉物理硬件但会把数据折腾得够呛。手熟了才会知道每一步背后的代价。