Linux磁盘分区全指南：从MBR/GPT到LVM在线扩容与故障修复-代码聚汇网

Linux磁盘分区全指南：从MBR/GPT到LVM在线扩容与故障修复

半泽和莉娜·2026-09-03·阅读 22 GEO检测（免费）

Linux分区MBRGPT

|难度：普通|阅读约 38 分钟

1. 分区前必须想清楚的几件事：分区不仅仅是切磁盘

我见过不少刚接触Linux的同事，拿到一台新服务器，第一反应就是“赶紧fdisk给它分个区”，结果过几个月就被自己当初的随意折腾得痛不欲生。分区这个操作，本质上不是在“切蛋糕”，而是在给整个系统的数据生命周期做一套最底层的规划。你的分区方案一旦落地，后面再想调整，轻则umount重挂，重则丢数据、重启起不来，代价非常大。

先说说分区的真正意义。很多人以为分区就是为了“把硬盘分成C盘D盘”，这只是表象。在Linux世界里，分区承担着三个核心职责：一是隔离故障域，某个分区写满了、文件系统损坏了，不至于整个系统直接瘫掉；二是控制增长边界，比如日志分区满了就只影响日志，不会把你的业务数据盘也挤爆；三是匹配使用场景，不同目录的读写频率、数据重要性、备份策略完全不同，把它们放在一起管理，等于把所有鸡蛋放在一个篮子里。

举个例子，我之前接手过一台跑着MySQL的服务器，根分区和数据分区混在一起，结果一条误操作的大SQL把磁盘写满，整台机器的日志、系统临时文件、数据库全挤在一堆，最后连SSH都登录不上去，只能去机房物理机接显示器救急。如果当初给 /var 单独分个区，就算日志把 /var 写满了，系统核心服务和数据库照样能跑，处理起来就是从从容容地清日志，而不是焦头烂额地抢修。这就是隔离故障域的典型价值。

那到底哪些目录值得单独分区？基于我多年的运维和装机经验，给你一套最常用的参考方案：

目录	是否建议独立分区	原因
`/`	必需	根分区是所有其他挂载点的底座
`/boot`	强烈建议	内核和启动文件独立，避免根分区满了导致系统无法引导
`/home`	视情况	多用户共享机器时强烈独立，个人单机可不分
`/var`	强烈建议	日志、缓存、邮件队列都在这里，最容易写满
`/tmp`	可选	部分安全加固场景会用noexec挂载单独分区
`/data`	生产必需	业务数据单独存放，备份、扩容、迁移都方便

关于 /boot，多说一句。很多人懒得单独分，觉得“我就一个根分区多省事”，但真等哪天根分区被塞满、内核升级又需要写入 /boot 时，你就会体会到什么叫欲哭无泪。系统启动时引导加载程序需要读取 /boot 里的内核文件，如果它和根分区一起被写满，你连新内核都装不进去，甚至可能开不了机。我个人的习惯是，/boot 分1GB到2GB，只放内核和引导相关文件，完全够用。

分区大小的预估也有讲究，很多新手栽在这里。如果只是装个个人桌面或学习环境，我给一个保底方案：/boot 1-2GB，/ 至少50GB，swap 设为你物理内存的1到1.5倍（如果你是16GB内存的机器，给16GB到24GB是合理的），剩下的全给 /home 或 /data。如果跑生产业务，就没有统一标准了，/var 建议至少给50GB以上用来放日志，/data 取决于你的业务数据增长速度，最好按“预计两年增长量再乘以1.5倍”来预留。记住一个原则：分区宁大勿小，缩容永远比扩容痛苦得多。

不过话说回来，上面的方案是针对传统物理分区。如果你用的是LVM或者云厂商的块存储，分区策略可以更激进一些，这个后面专门讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. MBR和GPT怎么选：分区表类型决定了磁盘的边界和兼容性

在你执行 fdisk 或 parted 之前，有个前置问题必须回答：这块磁盘到底该用MBR分区表还是GPT分区表？很多人直接按默认回车完事，结果等到后期想扩容、想加分区时才发现，当初的分区表选错了。

先说这两者最本质的区别。MBR（主引导记录） 是上世纪80年代的老设计，分区表一共只有64字节的空间，每条分区表项占16字节，所以最多只能记录4条主分区记录。更关键的是，整个分区编址基于32位逻辑块地址（LBA），每块扇区以512字节计算，寻址上限就是2TB左右。也就是说，超过2TB的磁盘你用MBR，要么认不全，要么只能当作多个2TB的分区来用，非常尴尬。

GPT（GUID分区表） 则是UEFI时代的标准，它用全局唯一标识符来标识每个分区，理论上分区数量和磁盘大小基本不受限制，单个分区最大可以到ZB级别（在可预见的未来用不完）。它还甩掉了一个MBR的老毛病——MBR的分区表只有一份，坏了就全完了；GPT在磁盘头部和尾部各存一份分区表，并且用CRC校验来保证完整性，坏了一份还能用另一份自愈。从数据安全性角度讲，GPT是压倒性胜出。

但这里有个耦合关系，你光决定分区表没用，还得看你的机器启动模式。如果你用的是传统Legacy BIOS引导，它只能识别MBR分区表，GPT分区表就没法从这块盘启动操作系统（数据盘倒是可以识别）。如果你用的是UEFI启动，那必须使用GPT分区表。从2010年之后的机器基本都支持UEFI，所以现在新装机的正确答案几乎都是GPT。除非你还在维护老掉牙的服务器，或者需要给某些特殊硬件设备做兼容镜像，才需要考虑MBR。

我在实际操作中一般这样判断——先看服务器或电脑的固件设置，现在是UEFI模式就无脑GPT；如果是Legacy模式，而且磁盘容量小于2TB、也不打算用UEFI启动，那MBR也行，反正数据盘无所谓。不过市面上的云主机和裸金属服务器，现在默认也都支持UEFI了。

那拿到一块新磁盘，怎么快速确认当前的分区表类型？用 fdisk -l 看输出末尾的“Disklabel type”，或者用 parted /dev/sdb print，输出里会直接写“Partition Table: gpt”还是“Partition Table: msdos”。

bash复制# 查看磁盘信息
fdisk -l /dev/sdb

# 或者
parted /dev/sdb print

msdos 在Linux里就代表MBR。另外还有个细节，向一块已有旧的MBR分区表的磁盘上装新系统，如果启动模式是UEFI，安装程序会提示“磁盘上没有检测到EFI系统分区”，这时建议直接把整块盘清掉换成GPT，避免后续出现混合分区表的奇怪问题。

还有一个常见疑问是：GPT能在MBR的机器上读出来吗？ 实际上，规范里有一项叫“保护性MBR”（Protective MBR），GPT磁盘的第一个扇区会留一个保护性MBR记录，它的作用是防止老旧工具误把GPT磁盘当成“未格式化磁盘”而整个覆盖掉。所以在大多数情况下，老BIOS只能把这个盘当成一个容量巨大的空盘，没法直接读取里面的GPT分区。如果你真的需要在老机器上插一块大容量数据盘，同时主板又不支持UEFI，那建议直接把整块盘用MBR方式分多个2TB分区使用，否则就是找罪受。

3. 从识别磁盘到完成挂载：fdisk和parted的完整实操流程

现在进入正题，一块全新磁盘从接入系统到真正能存数据，需要经过“识别磁盘 → 创建分区 → 刷新分区表 → 格式化 → 挂载 → 开机自动挂载”这几步。这个链路里的每一步都有讲究，我带你走一遍完整流程，附上常见踩坑点。

3.1 识别磁盘：别把盘认错了

新磁盘插上之后，使用 lsblk（list block devices）查看块设备列表，这是最直观的方式：

bash复制lsblk

输出里你会看到类似这样的信息：

code复制NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   100G  0 disk 
├─sda1   8:1    0     1G  0 part /boot
├─sda2   8:2    0    49G  0 part /
└─sda3   8:3    0    50G  0 part /data
sdb      8:16   0   500G  0 disk

看到 sdb 了吗？这就是我们新加的500G数据盘。在云服务器上，新挂载的云盘一般会显示为 vdb、sdb 之类的名字，视虚拟化驱动而定。强烈建议在动手之前用品牌、序列号、容量、总线位置多重确认一遍，别把系统盘给分了。可以用 lsblk -o NAME,SIZE,MODEL,SERIAL 查看磁盘的型号和序列号，线上环境多一步确认永远不亏。

3.2 创建分区：MBR用fdisk，GPT用parted或gdisk

如果确认是MBR需要，用 fdisk：

bash复制fdisk /dev/sdb

交互界面里输入 n 新建分区，选主分区（p），按提示设置分区号、起始扇区、结束扇区。比如要建一个200G的分区，可以直接输入 +200G 这样设置结束位置。分区建好后输入 w 写入并退出。

但我要提醒一句，现在新机器推荐的都是GPT，fdisk也可以操作GPT分区，但某些老版本的fdisk对GPT支持不够好，加上fdisk是基于传统的CHS架构思想设计的，遇到复杂的GPT操作（比如修改分区名、调整分区属性）不如parted灵活。所以我的习惯是：GPT用 parted 或 gdisk。

parted 的特点是用户可以非交互式地一行一行执行命令，非常适合脚本化：

bash复制# 将磁盘的分区表转换成GPT
parted /dev/sdb mklabel gpt

# 创建100%容量分区（从1MiB起始扇区，使用100%容量）
parted /dev/sdb mkpart primary 1MiB 100%

# 或者创建指定大小分区
parted /dev/sdb mkpart primary 1MiB 200GiB

1MiB 的起始位置其实是个小知识点，老教程推荐从扇区63或2048开始，是为了对齐历史上的磁道边界。现代磁盘和SSD建议从1MiB对齐，这样每个分区都恰好对齐到物理扇区和闪存页，对SSD性能和寿命都有好处。parted默认的1MiB就做了对齐，不用自己额外去算。想确认是否对齐，可以用：

bash复制parted /dev/sdb align-check optimal 1

如果返回 1 aligned，说明分区1已对齐。SSD用户强烈建议检查这一步，NVMe盘尤其重要。传统机械盘影响不大，但也不会错。

如果你更习惯fdisk的操作手感，可以装一个gdisk，它的交互逻辑和fdisk几乎一模一样，只是专为GPT设计：

bash复制gdisk /dev/sdb
# 在gdisk里输入 n 新建分区，w 写入

3.3 刷新分区表：让内核认到新分区

分区创建完成后，系统内核并不会立即认到新分区，特别是你在系统运行状态下给磁盘改了分区表。这时候需要通知内核重新读取：

bash复制partprobe /dev/sdb

partprobe 是parted自带的一个小工具，它的作用就是告诉内核“磁盘的分区表变了，重新读一下”。如果服务器上的磁盘在使用中，比如有文件系统已经被挂载了，你可能需要重启系统才能让内核完全刷新。遇到刷不出来就重启，这是老内核时代的老大难问题，但新版内核+partprobe基本都能解决。还有个特殊情况：如果某个分区正在被使用，partprobe可能提示“无法更新”，这时如果有办法安全卸载就先卸载，不然只能排队到重启。

刷新之后，再用 lsblk /dev/sdb 确认分区是否出现。你会看到 sdb1 这类的分区节点。

3.4 格式化：文件系统选型

分区创建好了，下一步是格式化。先选文件系统。常见的有：

ext4：老牌稳、兼容性最好，几乎所有Linux发行版都原生支持，日常使用首选。
xfs：RHEL/CentOS系默认文件系统，适合大文件、大容量场景，在单个文件大小、并发写入方面表现好，但扩容只能增不能减。
btrfs：支持快照、压缩、自愈等高级特性，功能强但复杂度和风险也高，生产环境建议谨慎。
zfs：数据完整性极强，但License和模块问题使得它在主流发行版上普及受限。

我这里给个实用建议：个人学习、通用服务器就用ext4；生产环境的CentOS/RHEL系服务器，用xfs；需要快照和高级特性的，再考虑btrfs。不要盲目追求“新潮”，文件系统稳定压倒一切。

格式化命令：

bash复制# ext4
mkfs.ext4 /dev/sdb1

# xfs
mkfs.xfs /dev/sdb1

格式化的时候有个特别容易犯的错——把盘号写错了，把 /dev/sdb1 写成 /dev/sdb，等于把整块盘重新格式化。这种事故一旦发生，数据基本无法找回。所以我在线上操作大容量磁盘时，一律先 lsblk 确认盘符，再在执行前看一眼命令，再三确认后按回车。

3.5 挂载与开机自动挂载：别让环境重启就打回原形

格式化完毕，创建挂载点目录，挂载：

bash复制mkdir -p /data
mount /dev/sdb1 /data

执行完 df -h 或 lsblk 就能看到分区已经被挂载到了 /data。但这里只是临时挂载，重启就没了。要做到开机自动挂载，需要写入 /etc/fstab。

/etc/fstab 是Linux系统启动时自动挂载文件系统的配置文件，格式如下：

code复制设备名  挂载点  文件系统类型  挂载选项  dump备份标记  fsck检查顺序

例如：

code复制/dev/sdb1  /data  ext4  defaults  0  0

但这里我要重点提醒：fstab里尽量不要写设备名，要写UUID。因为设备名在系统启动过程中可能因为磁盘识别顺序变化而漂移，今天sdb明天可能变成sdc，系统一重启挂载就失败了，严重的话会直接卡在紧急模式。UUID是文件系统创建时生成的全局唯一标识符，相对稳定得多。

获取UUID：

bash复制blkid /dev/sdb1

输出类似 UUID="a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx"。然后写入fstab：

code复制UUID=a1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx  /data  ext4  defaults  0  0

写完fstab后，强烈建议执行一次验证，确认语法没错：

bash复制mount -a

这条命令会按fstab内容重新挂载所有条目，如果有错误会直接报出来。你还可以用 findmnt /data 确认挂载是否生效。永远不要跳过这一步，fstab写错了最轻的是系统启动时提示A start job is running，等半天超时后进入紧急模式，严重时系统可能直接无法启动。万一真的启动进了紧急模式，用root密码进入后执行 mount -o remount,rw / 重新挂载根为可写，再修改fstab里错误的行，就能救回来。

4. LVM：给分区加上一层可以后悔的“保险”

如果你多管几年的服务器，你会慢慢意识到一个残酷的事实：传统物理分区的扩容太痛苦了。用fdisk或parted把分区建好、文件系统格式化好之后，想要扩大这个分区，路径极其曲折——如果分区后面的扇区被其他分区占了，根本没法扩；“磁盘满了”只能加新盘、迁移数据、重新分区。这套流程在生产环境里等于要停机窗口。

为了解决这个痛点，LVM（Logical Volume Manager，逻辑卷管理）出现了。它能让你像管理一块“虚拟大磁盘”一样，随时把新的物理磁盘加入存储池，弹性分配给需要的逻辑卷，扩容时在线操作，业务几乎无感知。

打个比方：物理分区就像你在老城区买死了一块地，地边界定了就不能动；LVM就像在一个大型仓库里用隔板划分区域，仓库总面积可以随着货架的增加而扩大，隔板也可以随时移动。仓库就是卷组（VG，Volume Group），货架就是物理卷（PV，Physical Volume），隔板划出来的区域就是逻辑卷（LV，Logical Volume）。

4.1 第一步：把物理磁盘变成物理卷（PV）

bash复制pvcreate /dev/sdb

这一步是把整块磁盘（或分区）初始化成LVM可以识别的物理卷。注意，这里的 /dev/sdb 可以是整块盘，也可以是 /dev/sdb1 这样的分区，两种方式都行，推荐使用整块盘，省一级分区管理。

创建好之后，用 pvs 或 pvdisplay 查看：

bash复制pvs

输出会显示PV的名称、所属卷组、总大小等信息，此时它还没被加入任何卷组，显示为空。

4.2 第二步：创建卷组（VG）

bash复制vgcreate datavg /dev/sdb

这条命令创建一个名为 datavg 的卷组，并把 /dev/sdb 这块盘放进去。卷组名自己取，别用中文和特殊符号。

以后你加新盘，想把它纳入同一个存储池，只需要：

bash复制vgextend datavg /dev/sdc

这样卷组的总可用空间就相当于两块盘之和，这就是“弹性”的来源。

4.3 第三步：在卷组里切出逻辑卷（LV）

bash复制lvcreate -n datalv -L 200G datavg

这行命令的含义是：在 datavg 卷组里创建一个叫 datalv 的逻辑卷，大小200G。你还可以使用 -l 100%FREE 把卷组剩余空间全部分配给逻辑卷：

bash复制lvcreate -n datalv -l 100%FREE datavg

创建完成后，逻辑卷的设备路径会出现在 /dev/mapper/datavg-datalv 或 /dev/datavg/datalv。注意，这个路径不是硬盘实际设备，它是LVM映射出来的虚拟设备。

4.4 第四步：格式化、挂载

和物理分区一样，逻辑卷也需要格式化：

bash复制mkfs.xfs /dev/datavg/datalv
mkdir -p /data
mount /dev/datavg/datalv /data

fstab里的写法同样是UUID优先，别写设备路径。

4.5 第五步：在线扩容，业务无感

等哪天你发现 /data 快满了，而卷组里还有剩余空间，直接扩展逻辑卷和文件系统：

bash复制# 先扩展逻辑卷大小，增加100G
lvextend -L +100G /dev/datavg/datalv

# 关键一步：同步扩展文件系统
xfs_growfs /data

如果你是ext4文件系统，同步扩展命令要用 resize2fs /dev/datavg/datalv。而且顺序必须是先扩逻辑卷、再扩文件系统，搞反了会报错。xfs_growfs的挂载点参数可以实时增长，完全不用卸载。

那卷组本身空间不够怎么办？加块新盘，vgextend datavg /dev/sdc 后再 lvextend，逻辑卷就变大了，整个链路全程在业务运行状态完成，不用停服下线。这就是LVM最吸引人的地方。

当然，LVM也并非没有缺点。它多了一层逻辑映射，对性能有一点微小的损耗，不过在现代硬件条件下基本感知不到。另外，如果物理盘坏了，LVM的恢复难度比独立分区要高，这也对备份策略提出了更高要求。但总体权衡下来，服务器数据盘我用LVM是常态，纯物理分区反而是特例。

5. 磁盘满了怎么办：清理、扩容和误操作修复的实战路径

“磁盘空间不足”大概是运维生涯中出现频率最高的报警之一。它不像硬件坏了那么惊悚，但解决不好会从报警升级成事故。

第一步永远是排查，先看空间使用率和inode使用率：

bash复制df -h
df -i

df -h 看的文件系统容量，df -i 看的是inode数量。很多人只关注前者，忘了后者。inode是文件系统里记录文件元数据的数据结构，每个文件或目录都要占一个inode。如果分区里文件数量太多，哪怕磁盘空间还有大量剩余，你也会收到“No space left on device”的报错。大目录、小文件多的场景特别容易出现这种情况，解决办法通常只能是删掉大量无用的小文件、缩小文件数量。

定位大文件占用，用du排查：

bash复制du -sh /data/*
du -sh /var/log/*

du 是沿着目录递归统计占用空间量的利器，通过一层层定位，找到最吃空间的目录。也可以直接用 ncdu 这个交互式工具，界面可视化程度高多了，TUI下按键盘上下键就能浏览各目录大小，排查效率高很多。如果系统里没装，包管理器直接装：

bash复制# Debian/Ubuntu
apt install -y ncdu

# RHEL/CentOS系
yum install -y ncdu

排查完之后常用对策：

系统日志是头号种子选手。journald日志堆积起来能轻松占用几十GB，限个大小，再手动收缩一下：

bash复制journalctl --vacuum-size=200M

这行命令会把旧日志清到剩余200M以内，立即腾空间。

清理软件包缓存。Debian系可以用 apt clean，RHEL系用 yum clean all 或 dnf clean all，清理后释放的空间量取决于你多久没清了。
Docker环境则要关注容器日志和镜像。容器日志默认不限制大小，日积月累很可怕。建议在 /etc/docker/daemon.json 中加日志轮转配置：

json复制{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

改完重启docker服务。这是很多新人都没提前做好的防御性配置，建议所有Docker宿主机提前加上。

如果清理到极限还是不够，那就得扩容。扩容有两条路径：LVM路径我已经讲过了，在线加盘、扩展卷组、扩展逻辑卷、增长文件系统即可，全程无感。但如果你当初没用LVM，是纯物理分区，情况就复杂了。一块盘上如果还有连续的未分配空间，可以用 growpart 来扩展分区：

bash复制growpart /dev/sdb 1

这个命令把 /dev/sdb 的第1个分区扩展到磁盘最大可用空间。扩展完再看文件系统：

bash复制# ext4
resize2fs /dev/sdb1
# xfs
xfs_growfs /data

注意，如果分区后面紧跟着别的分区，growpart 就无能为力了，因为物理上已经没有空闲空间。这时候只能“迁移大法”——把数据拷到新盘，重新分区并挂载。这也是为什么我一直强调规划分区的阶段就要想清楚：多给以后留点余地，少折腾未来。

另外一个很关键的坑是 swap分区的一个老问题。有些人在安装系统时swap给的特别大，占了几个G甚至几十个G，平时根本用不到，但分区又紧巴巴的。swap其实可以做成swap文件，而不是一个独立分区，按需创建和删除：

bash复制# 创建一个4G的swap文件
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# 如果要永久启用，写入fstab
/swapfile  none  swap  sw  0  0

想在系统运行时临时关掉swap释放空间：

bash复制swapoff -a

把swap空间返回到物理内存后，再用 free -h 确认。这种“swap分区改swap文件”的做法，也让分区规划更灵活。

6. 分区故障排查：那些栽过的跟头和必须知道的救命细节

最后一个大板块，聊聊分区的“翻车现场”。前面讲了一堆理论和操作，但实际生产环境里的坑远比教程复杂，我把踩过几次的典型问题罗列一下，希望你能少走弯路。

6.1 设备名漂移

前面提过一次，这里再展开。系统每次启动时，内核按探测顺序给磁盘分配设备名，但盘序在不同机器上不一定稳定。特别是服务器上有多块同型号硬盘的时候，今天 sdb 明天可能就变成了 sdc。如果你在fstab或者脚本里写死了设备名，开机就会挂载错盘——轻则挂载失败进紧急模式，重则把A盘的数据挂到B盘挂载点上，那画面太美我不敢看。

解决办法就是所有涉及持久挂载的地方统一用UUID。获取UUID用 blkid，也可以用 lsblk -f 查看：

bash复制lsblk -f

6.2 fstab写错导致系统启动崩溃

fstab写错是Linux新手最经典的翻车操作之一。尤其是数据盘挂载点写成了根目录、或者文件系统类型写错，系统启动的时候尝试挂载就会卡住或报错。更麻烦的是，有些云服务器默认系统盘root权限是只读的，你连改fstab都改不了。

抢救流程分享给你：

重启系统，在引导界面按 e 编辑引导参数。
找到 linux 开头的那一行，末尾追加 rd.break 或把 ro 改成 rw。
进入紧急shell或救援模式后，执行 mount -o remount,rw / 让根分区可写。
修改 /etc/fstab，注释掉或修正错误行。
重启验证。

不过这个流程在不同发行版上细节有差别，动手前搜索一下对应系统的救援模式操作。最好的办法还是防患于未然——写完fstab先 mount -a 测试，坚决不带病重启。

6.3 分区被占用，umount失败

磁盘卸载时经常报 target is busy，最常见原因是某个进程的工作目录在这个挂载点上，或者某进程正在使用这个目录下的文件。先 lsof +f -- /data 或 fuser -mv /data 找出占用进程，然后杀掉或让其切换目录，再卸载：

bash复制fuser -mv /data
# 或者直接杀掉占用进程
fuser -km /data

不要在业务高峰期对正在写入的磁盘执行umount，数据写到一半被中断，轻则文件系统报错，重则数据丢失。

6.4 云盘扩容后系统看不到新空间

云服务器上给云盘扩容之后，lsblk 看到的磁盘容量可能还是旧的。这是因为分区表没有同步。先确认物理盘容量变了：lsblk 看 sdb 这一行的是不是已经显示新容量。如果还是旧容量，可能需要重启云主机让虚拟化层重新同步。如果容量已变但分区没变（比如 /dev/sdb1 还是500G，但 /dev/sdb 已经显示1T），先 growpart /dev/sdb 1 扩展分区，再 resize2fs 或 xfs_growfs 扩展文件系统。

6.5 误删分区后的紧急救援

这个必须提一嘴，虽然不希望任何人用上。如果不小心用了fdisk把分区删了但还没写入，千万别慌，直接 w 退出，数据还在。如果已经写入，立刻停止对磁盘的一切写入操作，然后用 testdisk 来修复：

bash复制testdisk /dev/sdb

testdisk 会扫描磁盘上的分区表残留数据，通常能恢复被误删的分区信息。它是个交互式工具，界面看起来很像老式BIOS，但跟着提示走就行。越早操作成功率越高，要是误删后又往里写入了大量新数据，修复概率会直线下降。

6.6 4K对齐的隐形影响

机械硬盘时代，分区从扇区63开始是历史遗留问题，现代硬盘和SSD都是4K物理扇区，如果分区不对齐，读写时会出现“跨扇区”的额外IO，性能可能损失几个百分点甚至更多。用parted创建分区时默认1MiB对齐，这个没问题。但用某些老工具、或用安装程序自动分区时，要留意对齐状态。检查方式我前面写过：

bash复制parted /dev/sdb align-check optimal 1

如果返回不理想，最彻底的解决方式是重建分区——所以还是那句话，分区前想清楚，分区后少折腾。

分区这件事，看起来是一堆命令行操作，实际上考验的是你对数据生命周期、系统启动流程、业务增长预期的整体判断力。我最后再分享一个小习惯：每次分区操作前，用script命令记录整个操作过程：

bash复制script /var/log/disk-partition-$(date +%F).log

这样无论操作成功还是出了岔子，你都有完整的操作记录可以复盘。我这几年能在凌晨三点处理磁盘事故时不慌张，很大程度上就是靠着操作有记录这一条习惯。Linux分区不难，难的是每一步都经得起事后检验。