★ FEATURED ARTICLE 1. 先把需求想清楚什么场景下需要自己动手管理磁盘磁盘管理这活儿属于那种平时用不上、一用就要命的技能。大部分时候我们装完系统就丢一边等哪天发现根分区满了、数据盘没挂载、或者要扩容的时候才想起来分区、格式化、挂载、LVM 这套组合拳到底怎么打。我最早接触这是一台虚拟机磁盘空间告急根分区用得干干净净新加的数据盘又没法直接并入原来的存储。那时候不懂 LVM只能把数据倒腾出去重新分区折腾了一整晚。后来把 LVM 这套逻辑吃透了再遇到扩容就是几分钟的事。所以这篇内容我按实际操作顺序来讲分区、格式化、挂载、LVM每一步都给出可以直接抄的完整命令和参数说明同时把踩过的坑也一并交代。这套内容适合谁刚接触 Linux 服务器运维的开发者、准备自己搭 NAS 或实验室环境的学习者还有那些遇到磁盘不够用但不知道怎么扩的实战型选手。懂一点 Linux 基础命令就够不需要什么前置知识。1.1 磁盘管理到底在解决什么问题先说底层逻辑。操作系统要使用一块新磁盘必须经历三个阶段分区划分物理存储区域、格式化建立文件系统结构、挂载把文件系统接入目录树。缺少任何一步数据都落不到盘上。分区解决的是物理空间怎么切的问题类似买了一块很大的地皮你得先画红线把它切成几块地号。格式化解决的是每个地块怎么铺路盖房子的问题文件系统就是那套城市规划哪里放索引、哪里放数据、坏块怎么标记。挂载则是把建好的小区接入城市主干道让用户通过某个目录就能进出。这三步里最容易被忽视的是分区。很多新手以为新盘插上就能用实际上 Linux 不会自动帮新磁盘创建分区和文件系统哪怕你看到/dev/sdb出现在列表里没有格式化挂载之前它就是一块废铁。1.2 为什么 LVM 值得你多花半小时LVMLogical 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: w80G这种写法很常用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) quitparted 里一个很容易踩的坑是单位。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 主打快照、压缩、校验等高级特性但元数据开销大碎片问题在长时间运行后会显现生产环境部署需要更谨慎。家用实验环境体验新特性是不错的选择。我的选型建议场景推荐文件系统理由通用数据盘、系统盘ext4兼容性最好工具链成熟Red Hat 系默认安装XFS系统默认大文件性能好大量小文件、数据库XFS高并发写入表现佳家庭实验、需要快照Btrfs快照/压缩实用老内核环境2.6 之前ext3/ext4兼容性兜底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给文件系统打上标签之后挂载可以直接用LABELxxx代替设备路径管理多块盘时特别好用sudo mkfs.ext4 -L data_disk /dev/sdb1 # 之后挂载可写成 sudo mount LABELdata_disk /mnt/dataext4 的-m 0可以去掉默认保留块默认保留 5%。对大容量数据盘来说5% 就是好几 GB 的空间被锁死给 root 用磁盘纯粹做数据存储的话直接设成 0sudo mkfs.ext4 -m 0 /dev/sdb1XFS 的-f参数要特别注意它用于强制覆盖已有文件系统在脚本里如果判断不严很容易把有数据的盘直接抹掉。建议把mkfs.xfs -f写进脚本的人都在前面加一道确认逻辑我吃过这个亏。3.3 格式化前后的校验格式化之后不要急着挂载先做两步确认。第一步确认文件系统是否建成用blkid查看设备信息和 UUIDsudo blkid /dev/sdb1 # /dev/sdb1: UUIDxxxx-xxxx TYPEext4 PARTUUIDxxxx第二步做一次文件系统检查。ext4 用e2fsck -f /dev/sdb1XFS 用xfs_repair -n /dev/sdb1。注意 xfs_repair 只能对未挂载的文件系统执行而且-n是只检查不修复想真正修复才去掉-n。新格式化完成的盘一般情况下检查结果都是干净的但这个习惯养成了以后出问题时你不会一脸懵。4. 挂载mount 命令、fstab 自动挂载与 UUID4.1 mount 命令的基本用法格式化和分区都完成了现在要把文件系统接到目录树上这就是挂载。最基本的命令# 先创建挂载点目录 sudo mkdir -p /mnt/data # 挂载设备到目录 sudo mount /dev/sdb1 /mnt/data # 查看挂载结果 df -h挂载点目录可以是任意空目录但要注意如果目录里已有文件挂载后这些文件会被隐藏数据还在只是看不到直到卸载才恢复。所以我总是先确认目标目录是空的或者干脆新建专属目录。查看所有已挂载的文件系统# 带文件系统类型和挂载参数 mount | grep sdb1 # 或者简洁版 df -hTdf -hT这个命令建议成为肌肉记忆-h显示可读大小-T显示文件系统类型一眼就能看完整盘使用情况。4.2 fstab 自动挂载配置详解mount命令的挂载是临时的重启后失效。要实现开机自动挂载必须编辑/etc/fstab文件。fstab 的每一行有 6 个字段缺一不可设备标识 挂载点 文件系统类型 挂载选项 dump检查 fsck检查顺序一个标准的示例UUID5f2a0f1a-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 远程挂载则用vers4指定版本。第五字段表示是否用 dump 备份现代系统基本填 0。第六字段是 fsck 开机检查顺序根文件系统填 1其他非根填 2不需要检查填 0。顺序很重要填错了可能导致开机时系统花时间扫描非必要盘。改完 fstab 后别急着重启先执行这条命令验证配置是否正确sudo mount -a这条命令会按 fstab 文件重新挂载所有还没挂载的条目。如果没有任何报错fstab 语法十有八九没问题。如果报错立即修复否则下次重启会卡在 recovery mode 等待手动处理。4.3 挂载失败排查挂载不成功是最常见的问题这里给一个我自己的排查顺序lsblk确认设备节点存在。blkid确认设备已格式化且有文件系统。查看系统日志dmesg | tail内核会直接告诉你失败原因。确认挂载点目录存在且为空。检查 fstab 里设备标识是否写错mount -a模拟测试。遇到过最多的情况是这一步新盘格式化完直接在 fstab 里写了/dev/sdb1而不是 UUID后来插上别的盘导致设备名漂移开机就无法挂载了。所以 fstab 里一切以外设为主的设备我全都改成 UUID。另一个常见坑是权限问题在某些系统上普通用户挂载不了必须 sudo此时在 fstab 里加上user或users选项可以允许非 root 用户挂载。但代价是安全性降低生产环境别乱开。5. LVM 实战从创建到扩容缩容5.1 LVM 的架构概念LVM 的分层结构是我见过最容易讲清楚的四个名词一梳理就通PVPhysical Volume物理卷真正对应物理磁盘分区或整块磁盘的单元。VGVolume Group卷组多个 PV 汇聚成的资源池相当于一个虚拟的大仓库。LVLogical Volume逻辑卷从 VG 里划出来的逻辑分区最终在上面建文件系统。PEPhysical 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 中加入 # UUIDxxxx /mnt/data ext4 defaults 0 25.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 常见报错速查实际操作中遇到的问题翻来覆去就那几类整理成速查表供参考现象可能原因处理办法mount: unknown filesystem type xfs内核模块未加载执行modprobe xfs或查内核是否编译支持fdisk: cannot open /dev/sdb: No such file设备节点不存在或被占用lsblk确认设备名可能是/dev/nvme0n1而非/dev/sdb扩容后df -h大小没变只执行了 lvextend 忘了扩文件系统ext4 执行resize2fsXFS 执行xfs_growfsfstab 写错后开机卡在恢复模式挂载配置有问题输入 root 密码后修改/etc/fstab用mount -a测试mkfs.ext4: /dev/sdb1 is apparently in use分区还在被占用的卷组里先vgs/lvs确认是否在 LVM 中必要时vgreduce磁盘有空间但文件系统报No space leftinode 耗尽或保留块占满df -i查 inodetune2fs -m 0释放保留块最容易被忽略的是 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 层级关系每一步都有取舍。把这张图在脑子里建立起来以后遇到任何存储问题你至少知道问题出在哪一层、该去查什么工具。这是我做运维以来最深的一点感触——存储的坑从来不在工具多难用而在对层次关系的理解是否到位。
阅读完成 · 觉得有帮助？
