Linux磁盘管理实战：分区、格式化、挂载与LVM扩容

1. 先把需求想清楚：什么场景下需要自己动手管理磁盘

磁盘管理这活儿，属于那种"平时用不上、一用就要命"的技能。大部分时候我们装完系统就丢一边，等哪天发现根分区满了、数据盘没挂载、或者要扩容的时候，才想起来分区、格式化、挂载、LVM 这套组合拳到底怎么打。

我最早接触这是一台虚拟机磁盘空间告急，根分区用得干干净净，新加的数据盘又没法直接并入原来的存储。那时候不懂 LVM，只能把数据倒腾出去重新分区，折腾了一整晚。后来把 LVM 这套逻辑吃透了，再遇到扩容就是几分钟的事。所以这篇内容我按实际操作顺序来讲：分区、格式化、挂载、LVM，每一步都给出可以直接抄的完整命令和参数说明，同时把踩过的坑也一并交代。

这套内容适合谁？刚接触 Linux 服务器运维的开发者、准备自己搭 NAS 或实验室环境的学习者，还有那些遇到"磁盘不够用但不知道怎么扩"的实战型选手。懂一点 Linux 基础命令就够，不需要什么前置知识。

1.1 磁盘管理到底在解决什么问题

先说底层逻辑。操作系统要使用一块新磁盘，必须经历三个阶段：分区（划分物理存储区域）、格式化（建立文件系统结构）、挂载（把文件系统接入目录树）。缺少任何一步，数据都落不到盘上。

分区解决的是"物理空间怎么切"的问题，类似买了一块很大的地皮，你得先画红线把它切成几块地号。格式化解决的是"每个地块怎么铺路盖房子"的问题，文件系统就是那套城市规划：哪里放索引、哪里放数据、坏块怎么标记。挂载则是把建好的小区接入城市主干道，让用户通过某个目录就能进出。

这三步里最容易被忽视的是分区。很多新手以为新盘插上就能用，实际上 Linux 不会自动帮新磁盘创建分区和文件系统，哪怕你看到/dev/sdb出现在列表里，没有格式化挂载之前它就是一块废铁。

1.2 为什么 LVM 值得你多花半小时

LVM（Logical Volume Manager，逻辑卷管理）是在物理磁盘和文件系统之间加了一层抽象。它把多个物理分区或整块磁盘汇集成一个资源池，然后从这个池子里灵活划出逻辑卷给文件系统用。

没有 LVM 的扩容方式是灾难性的：分区建好了、文件系统格式好了、数据写满了，你想扩大这个分区，要么用有损工具冒着丢数据风险折腾，要么把数据搬到新盘再重建。有了 LVM，数据盘写满之后可以随时加入一块新磁盘，把新空间并入资源池，再在线扩大逻辑卷和文件系统，全程服务不中断。

我的观点是：凡是存放重要数据、预期会增长的存储路径，一律走 LVM。只有那种一次性固定大小、不打算扩容的临时盘（比如 swap 分区、一次性缓存盘）才可以不用 LVM。后面我会给出完整的 LVM 操作链路，照做就行。

2. 分区：MBR 与 GPT 的选择，以及 fdisk/parted 实战

2.1 MBR 和 GPT 怎么选

分区表是磁盘的第一层结构，它记录了磁盘上有哪些分区、从哪里开始到哪里结束。现在主流就两种：MBR 和 GPT。

MBR 是上世纪八十年代的老设计，分区表信息固定存放在磁盘开头的一段区域里，最多支持 4 个主分区，单分区最大 2TB。超过 2TB 的磁盘如果强制用 MBR，会把多余空间全部浪费掉，这是它最致命的限制。

GPT 是 UEFI 时代的新标准，没有 2TB 上限，主分区数量理论上不受限制，还带了冗余的分区表备份和 CRC 校验。现代服务器装系统默认就是 GPT，新磁盘做数据盘也建议直接选 GPT。

我的建议很简单：除了极老的机器或者必须兼容某些老引导器的场景，一律用 GPT。判断磁盘当前是哪种分区表，用fdisk -l就能看，输出里带 "Disklabel type: gpt" 的就是 GPT，带 "dos" 的就是 MBR。

2.2 fdisk 创建分区的完整流程

fdisk 是使用最广的交互式分区工具，新版 fdisk 已经支持 GPT，所以不需要额外学太多工具。下面用一块全新的/dev/sdb演示整个流程：

# 查看磁盘现状 lsblk # 输出示例： # NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT # sda 8:0 0 40G 0 disk # ├─sda1 8:1 0 1G 0 part /boot # └─sda2 8:2 0 39G 0 part / # sdb 8:16 0 100G 0 disk # 进入 fdisk 交互界面 sudo fdisk /dev/sdb

进入交互界面后依次输入：

# 新建 GPT 分区表 Command: g # 新建分区 Command: n # 分区号直接回车使用默认 Partition number (1-128): 回车 # 起始扇区直接回车使用默认 First sector: 回车 # 结束扇区，想用满全盘直接回车，想划分指定大小就写 +50G Last sector: +80G # 写入并退出 Command: w

+80G这种写法很常用，fdisk 支持+size{K,M,G,T,P}的简写，不需要去换算扇区数。实际项目中我经常在一块盘上划分两三个分区：一个做系统数据，一个做日志盘，一个留给备份目录，这样不同用途的数据在物理层面就隔离开了。

创建完分区后用partprobe让内核重新读取分区表，然后lsblk确认结果：

sudo partprobe lsblk # 此时应能看到 sdb1、sdb2 等新分区

2.3 parted 处理大容量磁盘的场景

fdisk 虽然支持 GPT，但在处理超大容量磁盘或者需要非交互式批量操作时，parted 更顺手。parted 最大的特点是所有操作一次性命令行完成，适合写进脚本。

看一个典型场景：一块 8TB 的新盘，需要被切成一个 3TB 分区和一个 5TB 分区：

# 直接指定磁盘，交互会弱很多 sudo parted /dev/sdc # 设置分区表类型 (parted) mklabel gpt # 创建第一个分区，从 0% 开始到 3TB (parted) mkpart primary 0% 3TB # 创建第二个分区，从 3TB 到磁盘末尾 (parted) mkpart primary 3TB 100% # 查看确认 (parted) print # 退出 (parted) quit

parted 里一个很容易踩的坑是单位。mkpart默认的起始单位是 MB，如果你输入0而不是0%，它会以 0 字节开始没问题，但如果输入3TB和3000GB，结果可能因为取整逻辑不同产生几 MB 的偏差。我习惯都用百分比或明确的TB/GB后缀，少踩换算的坑。

还有一个必须注意的操作：parted 的rm删分区危险程度极高，一旦执行很难恢复，每次回车前都要确认分区编号，我见过不止一次有人在print里看花了眼把想要的分区删了。

3. 格式化：文件系统选型与 mkfs 参数细节

3.1 ext4、XFS、Btrfs 怎么选

分区建好之后就是不空间，必须得建文件系统。Linux 生态里常见的文件系统就几个：ext4、XFS、Btrfs，还有面向特殊场景的 ZFS 和 f2fs，但日常用得最多的是前三个。

ext4 是目前兼容性最好的文件系统，几乎所有主流发行版都默认支持，从 U 盘到企业服务器都在用。它支持日志（journal）机制，突然断电后可以快速恢复文件系统一致性。缺点是单文件最大 16TB，单卷理论上限 1EB，但对绝大多数场景够用了。

XFS 是 Red Hat 系发行版（RHEL、CentOS、Fedora、Rocky）的默认文件系统，特别擅长处理大文件和高并发写入，缺点是删除大量小文件时性能一般，而且缩容基本不可行（几乎只能扩不能缩）。

Btrfs 主打快照、压缩、校验等高级特性，但元数据开销大，碎片问题在长时间运行后会显现，生产环境部署需要更谨慎。家用实验环境体验新特性是不错的选择。

我的选型建议：

3.2 mkfs 的关键参数

格式化命令格式为mkfs -t 文件系统类型 设备节点。举例：

# 格式化为 ext4 sudo mkfs.ext4 /dev/sdb1 # 格式化为 xfs sudo mkfs.xfs /dev/sdb1 # 格式化为 btrfs sudo mkfs.btrfs /dev/sdb1

几个我常用到的重要参数先说清楚。

ext4 的-L label给文件系统打上标签，之后挂载可以直接用LABEL=xxx代替设备路径，管理多块盘时特别好用：

sudo mkfs.ext4 -L data_disk /dev/sdb1 # 之后挂载可写成 sudo mount LABEL=data_disk /mnt/data

ext4 的-m 0可以去掉默认保留块（默认保留 5%）。对大容量数据盘来说，5% 就是好几 GB 的空间被锁死给 root 用，磁盘纯粹做数据存储的话直接设成 0：

sudo mkfs.ext4 -m 0 /dev/sdb1

XFS 的-f参数要特别注意，它用于强制覆盖已有文件系统，在脚本里如果判断不严很容易把有数据的盘直接抹掉。建议把mkfs.xfs -f写进脚本的人都在前面加一道确认逻辑，我吃过这个亏。

3.3 格式化前后的校验

格式化之后不要急着挂载，先做两步确认。

第一步确认文件系统是否建成，用blkid查看设备信息和 UUID：

sudo blkid /dev/sdb1 # /dev/sdb1: UUID="xxxx-xxxx" TYPE="ext4" PARTUUID="xxxx"

第二步做一次文件系统检查。ext4 用e2fsck -f /dev/sdb1，XFS 用xfs_repair -n /dev/sdb1。注意 xfs_repair 只能对未挂载的文件系统执行，而且-n是只检查不修复，想真正修复才去掉-n。新格式化完成的盘一般情况下检查结果都是干净的，但这个习惯养成了，以后出问题时你不会一脸懵。

4. 挂载：mount 命令、fstab 自动挂载与 UUID

4.1 mount 命令的基本用法

格式化和分区都完成了，现在要把文件系统接到目录树上，这就是挂载。最基本的命令：

# 先创建挂载点目录 sudo mkdir -p /mnt/data # 挂载设备到目录 sudo mount /dev/sdb1 /mnt/data # 查看挂载结果 df -h

挂载点目录可以是任意空目录，但要注意：如果目录里已有文件，挂载后这些文件会被隐藏（数据还在，只是看不到），直到卸载才恢复。所以我总是先确认目标目录是空的，或者干脆新建专属目录。

查看所有已挂载的文件系统：

# 带文件系统类型和挂载参数 mount | grep sdb1 # 或者简洁版 df -hT

df -hT这个命令建议成为肌肉记忆，-h显示可读大小，-T显示文件系统类型，一眼就能看完整盘使用情况。

4.2 fstab 自动挂载配置详解

mount命令的挂载是临时的，重启后失效。要实现开机自动挂载，必须编辑/etc/fstab文件。fstab 的每一行有 6 个字段，缺一不可：

设备标识 挂载点 文件系统类型 挂载选项 dump检查 fsck检查顺序

一个标准的示例：

UUID=5f2a0f1a-3b4c-4d5e-8f9a-0b1c2d3e4f5a /mnt/data ext4 defaults 0 2

逐项解释：

第一字段"设备标识"，强烈推荐用 UUID 而不是/dev/sdb1。原因很简单：设备名会随着内核识别顺序变化而变化，比如你插拔了一块 U 盘，原本的/dev/sdb1可能变成/dev/sdc1，但 UUID 是文件系统创建时生成且唯一的，不会变。用blkid就能查到 UUID。

第二字段挂载点。第三字段文件系统类型。第四字段挂载选项，最常用的是defaults，它等同于rw,suid,dev,exec,auto,nouser,async的组合。实际项目里我还会针对特定目录加额外选项：

• 数据库数据目录加noatime，禁止访问时间更新，减少写入量提升性能。
• 普通共享盘加rw,noexec，防止有人在这个盘上跑可执行程序，提升安全性。
• NFS 远程挂载则用vers=4指定版本。

第五字段表示是否用 dump 备份，现代系统基本填 0。第六字段是 fsck 开机检查顺序，根文件系统填 1，其他非根填 2，不需要检查填 0。顺序很重要，填错了可能导致开机时系统花时间扫描非必要盘。

改完 fstab 后别急着重启，先执行这条命令验证配置是否正确：

sudo mount -a

这条命令会按 fstab 文件重新挂载所有还没挂载的条目。如果没有任何报错，fstab 语法十有八九没问题。如果报错，立即修复，否则下次重启会卡在 recovery mode 等待手动处理。

4.3 挂载失败排查

挂载不成功是最常见的问题，这里给一个我自己的排查顺序：

1. lsblk确认设备节点存在。
2. blkid确认设备已格式化且有文件系统。
3. 查看系统日志dmesg | tail，内核会直接告诉你失败原因。
4. 确认挂载点目录存在且为空。
5. 检查 fstab 里设备标识是否写错，mount -a模拟测试。

遇到过最多的情况是这一步：新盘格式化完，直接在 fstab 里写了/dev/sdb1而不是 UUID，后来插上别的盘导致设备名漂移，开机就无法挂载了。所以 fstab 里一切以外设为主的设备，我全都改成 UUID。

另一个常见坑是权限问题：在某些系统上普通用户挂载不了，必须 sudo，此时在 fstab 里加上user或users选项可以允许非 root 用户挂载。但代价是安全性降低，生产环境别乱开。

5. LVM 实战：从创建到扩容缩容

5.1 LVM 的架构概念

LVM 的分层结构是我见过最容易讲清楚的，四个名词一梳理就通：

• PV（Physical Volume，物理卷）：真正对应物理磁盘分区或整块磁盘的单元。
• VG（Volume Group，卷组）：多个 PV 汇聚成的资源池，相当于一个虚拟的"大仓库"。
• LV（Logical Volume，逻辑卷）：从 VG 里划出来的逻辑分区，最终在上面建文件系统。
• PE（Physical Extent，物理扩展块）：VG 空间分配的最小单位，默认 4MB，类似内存分页。

从使用者的角度看，整个过程就是在做一件事：把物理盘的零散空间收拢成一个池子，再按需放水。池子里的水不够了，就并一块新盘进来；某条水渠不够宽了，就从池子里多放点水给它，全程不用停水。

5.2 创建 PV、VG、LV 的完整流程

依然拿/dev/sdb举例，完整创建一套 LVM 逻辑卷：

# 第一步：创建物理卷 sudo pvcreate /dev/sdb # 查看 PV 建立结果 sudo pvs # PV VG Fmt Attr PSize PFree # /dev/sdb lvm2 --- 100.00G 100.00G # 第二步：创建卷组 vg_data sudo vgcreate vg_data /dev/sdb # 查看 VG sudo vgs # 第三步：从 vg_data 创建逻辑卷 lv_data，指定 80G sudo lvcreate -L 80G -n lv_data vg_data # 第四步：在逻辑卷上格式化并挂载 sudo mkfs.ext4 -m 0 /dev/vg_data/lv_data sudo mkdir -p /mnt/data sudo mount /dev/vg_data/lv_data /mnt/data

这里有一个关于空间分配的细节。lvcreate -L 80G指定的是逻辑卷大小，而-l 100%FREE是另一种更常用的写法——把 VG 里所有剩余空间一次性分配给这个逻辑卷。如果你在 VG 里只建一个 LV，直接-l 100%FREE最省事，不会因为估算错误留下碎片空间。

创建完 LVM 逻辑卷后，设备路径有两种写法：一种是/dev/vg_data/lv_data（通过设备映射生成的易读路径），一种是/dev/mapper/vg_data-lv_data（内核实际使用的符号链接）。两者指向同一个设备，fstab 里两种都能用，我习惯用/dev/mapper/前缀的形式，因为它在某些发行版上兼容性更好。

挂载后别忘写入 fstab 实现开机自动挂载：

# 获取 UUID sudo blkid /dev/vg_data/lv_data # 在 /etc/fstab 中加入 # UUID=xxxx /mnt/data ext4 defaults 0 2

5.3 在线扩容实战

LVM 最核心的价值体现就在扩容。场景还原：上面建的 lv_data 现在 80G 用满了，VG 里还剩 20G 空闲，我们要把逻辑卷扩到 120G。

扩容分三步，顺序不能乱：

# 第一步：扩展逻辑卷容量 sudo lvextend -L +40G /dev/vg_data/lv_data # 或者直接指定目标大小 sudo lvextend -L 120G /dev/vg_data/lv_data # 第二步：扩展文件系统容量 # ext4 用 sudo resize2fs /dev/vg_data/lv_data # XFS 用 sudo xfs_growfs /mnt/data # 第三步：确认结果 df -h /mnt/data

第一步和第二步必须配套执行。只执行lvextend而不执行第二步，逻辑卷变大了但文件系统不知道自己有这么大，df看到的大小还是原样。反过来，文件系统扩展必须在逻辑卷扩展之后执行。

XFS 和 ext4 的第二部区别很大：XFS 的xfs_growfs挂载状态下就能执行，而且只需要指定挂载点，不需要指定设备路径；ext4 的resize2fs也可以在挂载状态下在线执行，但有些旧内核版本不支持在线 resize，遇到报错就先卸载再执行。

等 VG 的剩余空间都用完还想扩容时，就需要把新磁盘并入 VG：

# 新盘 /dev/sdc 加入卷组 sudo pvcreate /dev/sdc sudo vgextend vg_data /dev/sdc # 然后重复上面的 lvextend + resize2fs/xfs_growfs sudo lvextend -L +100G /dev/vg_data/lv_data sudo resize2fs /dev/vg_data/lv_data

这个过程完全不中断服务，数据盘上跑着的业务没有任何感知。我在生产环境做过多次这样的操作，只要按顺序执行且磁盘本身没问题，成功率接近百分之百。

5.4 缩容操作

说实话，LVM 的缩容远比扩容复杂且危险，生产环境我基本不碰。但既然是实战，我把流程写清楚，也把风险交代明白。

缩容的基本逻辑是：先缩文件系统，再缩逻辑卷，最后回收 VG 空间。顺序和扩容恰好相反。

# 第一步：卸载文件系统 sudo umount /mnt/data # 第二步：检查文件系统完整性（缩容前强制检查！） sudo e2fsck -f /dev/vg_data/lv_data # 第三步：缩小文件系统到 50G sudo resize2fs /dev/vg_data/lv_data 50G # 第四步：缩小逻辑卷到 50G sudo lvreduce -L 50G /dev/vg_data/lv_data # 第五步：重新挂载 sudo mount /dev/vg_data/lv_data /mnt/data

先缩文件系统再缩逻辑卷这个顺序是最关键的，如果反了——先把逻辑卷缩到 50G 再来缩文件系统，文件系统会认为设备大小低于它当前认为的容量，直接拒绝工作，甚至引发数据损坏。

XFS 文件系统不支持缩容，这是它的硬性限制。如果你的 XFS 卷空间规划失误需要收缩，只能把数据导出重建，没有在线缩容的办法。所以规划时我通常给 XFS 卷预留充足余量，宁可多给一点空间也别后续返工。

另一点必须强调：缩容前务必备份。e2fsck 之后缩容原则上安全，但遇到断电、系统崩溃等意外，缩容到一半的数据盘恢复难度非常大。我把最值钱的数据从来都放在扩容友好、且有备份措施的盘上，缩容这种操作等着演练环境做就好。

6. 常见问题与避坑经验

6.1 常见报错速查

实际操作中遇到的问题翻来覆去就那几类，整理成速查表供参考：

最容易被忽略的是 inode 耗尽问题。磁盘剩余空间很多，但文件系统 inode 用完了，一样写不进数据。特别是邮件目录、缓存目录这种海量小文件场景，默认 inode 数量很容易被吃光。所以遇到"明明空间够却写不进去"，第一件事看df -i，而不是怀疑磁盘满了。

6.2 我的几条实操心得

最后说几条从多次折腾里沉淀下来的经验。

第一，任何格式化、分区、缩容操作前，先确认这盘上有没有需要保留的数据。这个确认不是看一眼就觉得没有，而是blkid查文件系统、mount查挂载现状、df查使用情况，三步走完才敢动手。我见过有人照着教程对着一块包含旧数据的盘直接mkfs，教训很惨痛。

第二，fstab 的改动一定要用mount -a验证。我每次改完 fstab 都会执行这个命令，模拟系统启动时的挂载行为，确认没问题再放心重启。这一步十几秒钟，能省掉一次远程服务器失联的麻烦。

第三，生产环境的 LVM 扩展要按"检查 VG 空间 → lvextend → resize2fs/xfs_growfs → df 确认"的顺序做，每完成一步都确认结果再下一步。顺序混乱是扩容出错最常见的原因。

第四，新买的盘或新创建的卷，建议在正式使用前做一次读写测试。dd写一块临时文件再删掉，或者用badblocks扫描一遍，能在早期发现磁盘坏道问题，预防比事后恢复香得多。

磁盘管理真正难的不是单条命令，而是整体流程图：分区表选型、文件系统选型、挂载持久化、LVM 层级关系，每一步都有取舍。把这张图在脑子里建立起来，以后遇到任何存储问题，你至少知道问题出在哪一层、该去查什么工具。这是我做运维以来最深的一点感触——存储的坑从来不在工具多难用，而在对层次关系的理解是否到位。