1. 先想清楚这四个存储方案到底在解决什么问题先说个判断很多刚接触 Linux 服务器的人容易把磁盘管理简单理解成分区、格式化、挂载。真到了生产环境这套思维根本扛不住事——你总会遇到根分区不够了磁盘阵列里坏了一块盘要备份几十 TB 数据但不想再买一台服务器这类现实问题。这时候如果脑子里只有 fdisk 那三板斧大概率会当场抓瞎。这个项目标题把标准分区、LVM、软件 RAID、ZFS 放在一起不是随便拼凑的四样东西它们其实是 Linux 存储管理的四个递进层次分别解决不同维度的痛点标准分区解决的是如何把一块裸盘变成能用的空间这是地基LVM 解决的是空间不够了怎么办它把物理磁盘抽象成了可以动态调整的逻辑卷软件 RAID 解决的是盘坏了数据会不会丢、读写能不能快一点它用多块盘实现冗余和性能ZFS 则是一个集大成者它把卷管理、文件系统、校验、快照、压缩全部整合在一起思路跟传统方案完全不同。我在实际培训中见过太多人从第一层直接跳到第四层结果把 ZFS 用得像个普通格式化工具一样完全没发挥它的优势。所以这篇实操笔记我按从基础到进阶、从普通到特殊的路线来写每一步都带上我踩过的坑和实测过的命令尽量让你看完就能动手复现。适合读这篇内容的人我大概分三类一是刚入门 Linux 运维、想系统补上存储这块短板的同学二是要从临时处理一下磁盘升级到正经设计一套存储方案的开发者三是已经用过其中一两样、但没成体系串起来的人。如果你属于任何一类这篇应该对你有点用。2. 不补不行的基础标准分区到底怎么理解才算透2.1 分区表类型、对齐和文件系统这些坑别等爆了才学先说分区表。现在主流是 MBR 和 GPT 两种。MBR 最多支持 2TB 和 4 个主分区超过这个容量就得用 GPT。我见过不少同事在给 4TB 盘分区时还在用 fdisk结果 fdisk 默认显示的是 MBR 模式分完区系统只认得出 2TB剩下空间直接蒸发。这事在黑五采购大容量硬盘后特别容易发生。所以建议直接把分区表工具默认思维改成 GPT。在 RHEL 系列、Ubuntu 这些现代发行版上用 parted 或 fdisk 新建分区时直接选 gpt 标签省得后面返工。另一个容易忽略的是分区对齐。老式分区默认从第 63 扇区开始现代硬盘物理扇区是 4096 字节如果逻辑分区起始位置没对齐到 8 的整数倍扇区1MiB 对齐性能会有肉眼可见的下降尤其是跑数据库这类随机读写场景。实际操作里parted 和 fdisk 现在默认都会做对齐但你用脚本或旧工具时一定要手动指定起始位置比如从 2048s 开始。这算是最容易踩的隐形坑。文件系统方面ext4 和 xfs 是 Linux 上最容易遇到的两个。RHEL 系列默认 xfsDebian/Ubuntu 默认 ext4。xfs 胜在稳定性和对大文件、大容量的支持但有一个很大的限制不支持缩容。ext4 则比较灵活可以扩也可以缩。新手如果不清楚这个区别后面 LVM 缩容那一节会直接卡住。2.2 fdisk 实战创建 GPT 分区并挂载完整命令演示我拿一块新加的 1TB 虚拟磁盘做演示设备名假设是 /dev/vdb云主机上常见操作流程如下# 1. 确认磁盘是否已被系统识别 lsblk # 输出里应该能看到 vdb如果没有可能是云平台没挂载先去控制台挂载或执行 rescan-scsi-bus.sh部分系统 # 2. 用 fdisk 进入交互式分区 sudo fdisk /dev/vdb在 fdisk 交互界面里依次输入g # 创建新的 GPT 分区表 n # 新建分区 回车 # 分区号默认即可 回车 # 起始扇区默认会帮你对齐 回车 # 结束扇区默认是磁盘末尾即整个盘一个分区 w # 写入并退出退出后再执行sudo partprobe /dev/vdb让内核重新读取分区表。接着格式化并挂载sudo mkfs.xfs /dev/vdb1 sudo mkdir -p /data sudo mount /dev/vdb1 /data但这里有个新手很容易犯的错误直接 mount 挂载服务器重启后分区不会自动挂载除非写进 /etc/fstab。我的习惯是查看分区的 UUID 再写 fstab而不是直接写设备名因为设备名在重启后可能变化。sudo blkid /dev/vdb1 # 假设输出/dev/vdb1: UUIDxxxx-xxxx TYPExfs # 然后编辑 /etc/fstab 添加一行 # UUIDxxxx-xxxx /data xfs defaults 0 0这里有个验证技巧mount -a执行后没有报错说明 fstab 配置没问题。如果你写错了重启就会直接进入 emergency mode那滋味可不好受。2.3 什么时候你根本不需要分区说出这句话可能会让一些传统运维皱眉但我的实际经验是很多时候整块盘直接格式化挂载性能和维护上都更省心。分区的意义在于隔离、双系统引导、以及某些特殊场景但纯数据盘完全没必要分区。原因很简单如果以后这块盘要扩容云平台加一块更大的盘、然后你用 LVM 把它纳入卷组比在分区表层面搞 resize 要安全得多。另外 SSD 存在预留空间管理分区表多一层反而多一个故障点。在数据盘上我通常用 LVM 替代分区或者干脆裸盘格式化。那标准分区还有什么不可替代的场景系统盘引导/boot 分区、双系统、需要固定大小留给 swap 分区的时候。其他情况我基本都建议走 LVM。3. LVM 扩缩容实操我在扩容现场踩过的坑全记录3.1 LVM 的卷组、物理卷、逻辑卷到底是怎么一个三层结构LVM 的核心思路是把物理磁盘这一层抽象成空间池然后用的时候从池里划。整个过程是三层结构物理卷 PVPhysical Volume、卷组 VGVolume Group、逻辑卷 LVLogical Volume。打个生活化的比方PV 是你家买回来的整袋大米VG 是你把所有大米倒进同一个米缸LV 是你从米缸里舀出来的一碗文件系统是这碗大米煮出来的饭。你随时可以从米缸里再舀一碗也可以把一碗倒回去但前提是米缸里有米——也就是 VG 里有空闲空间。创建 LVM 的手动步骤看起来不复杂但每一步都有讲究。先给盘做 PVsudo pvcreate /dev/vdb1 sudo vgcreate vg_data /dev/vdb1 sudo lvcreate -L 200G -n lv_web vg_data sudo mkfs.xfs /dev/vg_data/lv_web sudo mount /dev/vg_data/lv_web /data这里有两个细节值得注意。一是 PEPhysical Extent大小它是 VG 内部空间分配的最小单位默认 4MiB。如果你只有几个小盘4MiB 没问题但如果你的 VG 要放几百 TB 的超大存储池建议vgcreate -s 16M或更大减少元数据膨胀。第二是 lvcreate 的-L和-l两个参数区别-L接具体大小-l接 PE 数量或百分比比如-l 100%FREE表示用掉卷组里所有剩余空间。3.2 扩容在线的完整步骤xfs 和 ext4 的顺序不能搞反真实场景是这样的某天某应用报磁盘满进服务器一看/data已经 98% 了。我当时的操作就是标准的 LVM 在线扩容流程全程服务不用停。# 1. 查看当前状态 df -h /data lvs vgs # 2. 如果 VG 剩余空间不足先扩 VG # 新加了 /dev/vdc 整盘先建 PV 再并入 VG pvcreate /dev/vdc vgextend vg_data /dev/vdc # 3. 扩展 LV注意 号是增加不带 号是扩展到指定大小 lvextend -L 100G /dev/vg_data/lv_web # 4. 扩展文件系统这步最容易被搞错 xfs_growfs /data # 如果你是 xfs用这个注意不能指定设备名要指定挂载点 resize2fs /dev/vg_data/lv_web # 如果你是 ext4用这个我见过最典型的翻车现场是两个顺序问题第一扩完 LV 忘了扩文件系统命令也执行了但 df 一看还是原大小第二在 xfs 上用了 resize2fs直接报错说不认识这个文件系统。所以一定要先确认你的文件系统类型再选命令。另外一个坑xfs_growfs 需要在挂载状态下、以挂载点为参数执行。如果你因为在维护模式下没法挂载那就用xfs_growfs -d /dev/vg_data/lv_web指定设备这个用法在部分版本上支持但不如挂载点稳。建议还是老老实实挂载上去再扩。3.3 缩容流程ext4 可缩、xfs 不可缩这个结论你怎么记住缩容是 LVM 里最危险的操作没有之一。我强烈建议只在两种情况下做缩容一是测试环境练习二是你确认可以卸载文件系统并且有备份。生产环境里缩容前如果没有做备份一旦搞错中间状态数据可能全没。xfs 不支持缩容这是文件系统层面的硬限制不要在 xfs 的 LV 上尝试lvreduce大概率会损坏文件系统。ext4 可以缩但顺序是反的先缩文件系统再缩 LV。顺序不能反反了就会造成文件系统超出设备边界直接数据损坏。# 假设要把 /dev/vg_data/lv_web 缩到 150G当前 200Gext4 文件系统 # 1. 卸载必须的 umount /data # 2. 检查文件系统e2fsck 不能跳 e2fsck -f /dev/vg_data/lv_web # 3. 先缩文件系统到 150G resize2fs /dev/vg_data/lv_web 150G # 4. 再缩 LV 到 150G注意这里没有 号 lvreduce -L 150G /dev/vg_data/lv_web # 5. 重新挂载验证数据完整性 mount /dev/vg_data/lv_web /data我早期犯过一个错文件系统缩到 150G 后LV 忘记缩然后 VG 里的空闲空间一直没多出来。后来另一个分区告急时才发现几吉空闲空间白白躺在那里。缩容时一定要两步连着做完中途不要切去做别的操作。3.4 LVM 的高级操作快照和元数据恢复关键时刻能救命LVM 快照是个好东西但很多初学者对它抱有错误期待。快照不是备份它是基于写时复制Copy-on-Write机制的一份当时状态的照片。在快照创建之后原始数据发生修改时旧数据会被复制到快照区域所以通过快照可以看到旧版本。创建快照的典型用途是给数据库做备份前的一致点比如给某应用的 LV 做快照然后直接从快照挂载出来跑备份不影响线上数据。lvcreate -L 10G -s -n lv_web_snap /dev/vg_data/lv_web mkdir /snap_mnt mount /dev/vg_data/lv_web_snap /snap_mnt # 备份完成之后卸载并移除快照 umount /snap_mnt lvremove /dev/vg_data/lv_web_snap快照区域的大小要留够如果写时复制的量超过快照空间快照就会失效变成 invalid不能再挂载。所以快照大小至少要预估一下在快照存活期间会有多少数据被修改。另一个值得记住的是 LVM 元数据备份。每次修改 VG 或 LV 时系统都会自动在 /etc/lvm/backup 下生成备份在 /etc/lvm/archive 下生成归档。如果你误删了 LV可以用vgcfgrestore找回来。# 查看卷组信息 vgcfgbackup vg_data # 如果误操作需要恢复先查看备份时间线 ls /etc/lvm/archive/ # 恢复 vgcfgrestore -f /etc/lvm/archive/vg_data_xxxx.vg vg_data这个操作我实际只救过一次但那次就值回票价了。一个同事在生产环境误删了某测试库的 LV当时数据库还没正式启用靠 vgcfgrestore 恢复了 LV 结构数据文件完好无损。4. 软 RAID 全解析mdadm 从建阵列到故障替换的完整笔记4.1 软 RAID 和硬 RAID 怎么选级别别拍脑袋决定软 RAID 用 CPU 和内核 md 模块实现阵列逻辑硬 RAID 依赖专用 RAID 卡。如果你买的是正经服务器有带电池的 RAID 卡硬 RAID 在性能上通常更好但云主机、虚拟机、实验环境这些场景软 RAID 反而是更合适的选择——没有额外硬件成本系统重装后阵列信息也更容易恢复。软 RAID 的常见级别我整理过一张对比表级别最小盘数容量利用率容错能力性能特征适用场景RAID 02100%无读写都提升缓存、临时数据RAID 1250%1 块盘故障读提升、写略降系统盘、数据库日志RAID 53(N-1)/N1 块盘故障读写均衡通用存储RAID 64(N-2)/N2 块盘故障写性能偏低大容量数据RAID 10450%每组1块读写都好数据库、虚拟化我在实际生产中最常用的是 RAID 1 给系统盘、RAID 10 给数据库RAID 5/6 在软 RAID 上要注意重建时的性能开销和故障概率。不建议把所有盘放一个 RAID 5 组盘越多重建时间越长重建期间如果另一块盘也挂了整个阵列就报废了。4.2 用 mdadm 创建 RAID 10 阵列一条命令讲清楚所有参数以四块 1TB 盘 /dev/sdb /dev/sdc /dev/sdd /dev/sde 创建 RAID 10 为例# 首先确保 mdadm 已安装 sudo mdadm --detail-platform # 检查软 RAID 支持 sudo apt install mdadm # Debian/Ubuntu sudo yum install mdadm # RHEL 系列 # 创建 RAID 10注意 metadata 版本用 1.2兼容性和恢复性最好 sudo mdadm --create /dev/md0 --level10 --raid-devices4 \ --metadata1.2 /dev/sdb /dev/sdc /dev/sdd /dev/sde创建命令执行后阵列会进入初始同步状态用/proc/mdstat查看进度cat /proc/mdstat # 输出类似md0 : active raid10 sde[3] sdd[2] sdc[1] sdb[0] # 1515136 blocks super 1.2 level 10, 128k chunk, algorithm 2 [4/4] [UUUU] # [...........] resync 47.8% (742400/1515136) finish2.1min创建期间不要急着格式化使用等 resync 完成后再 mkfs。初始同步期间系统 I/O 会明显变慢正常现象。RAID 10 的布局默认是近布局near还有一种远布局far适合连续读场景。创建时可以加--layoutf2指定但这个参数理解起来比较复杂日常不用动。4.3 阵列的日常维护监控、故障模拟和热备盘阵列创建完不是一劳永逸的日常监控最重要。我习惯把 mdadm 的监控写进 cron 或 systemd timer定期检查阵列状态# 每 10 分钟检查一次有故障就发邮件告警 sudo mdadm --monitor --scan --test -s # 或者直接查看 cat /proc/mdstat sudo mdadm --detail /dev/md0模拟一块盘故障然后替换# 标记 sdc 为故障 sudo mdadm --fail /dev/md0 /dev/sdc # 从阵列中移除 sudo mdadm --remove /dev/md0 /dev/sdc # 插入新盘 sudo mdadm --add /dev/md0 /dev/sdf新盘会自动变成 spare 并开始重建。这个过程里我踩过一个大坑如果新盘上有残留的文件系统签名或 RAID 元数据mdadm 会拒绝添加。解决办法是先清掉签名sudo wipefs -a /dev/sdf然后重新 add。这也是为什么我建议在数组创建前就用 wipefs 把所有盘清干净避免各种莫名的兼容问题。4.4 软 RAID 和 LVM 怎么配合使用顺序很关键很多新人搞不清楚软 RAID 和 LVM 的关系其实它们的合作模式很成熟先用软 RAID 把多块盘合成一个可靠的逻辑盘比如 /dev/md0然后在这个 md 设备上建立 PV、创建 LVM这样做的好处是既能享受 RAID 的冗余又能享受 LVM 的灵活扩缩容。pvcreate /dev/md0 vgcreate vg_raid /dev/md0 lvcreate -L 1.5T -n lv_data vg_raid mkfs.xfs /dev/vg_raid/lv_data mount /dev/vg_raid/lv_data /data但是要注意不要在 LVM 之上再叠加 RAID比如把一个 LV 拿去当 mdadm 的成员盘这就多了一层毫无意义的映射性能反而更差。正确思维是 RAID 在底层LVM 在上层。4.5 用 loop 设备在单机上模拟多盘 RAID练习必备如果你手头只有一台电脑、不想拆机或没有云盘资源loop 设备是最方便的练习方式。原理就是把一个大文件当成一块块磁盘来用# 创建 4 个 1G 的虚拟磁盘文件 dd if/dev/zero of/tmp/disk1.img bs1M count1024 dd if/dev/zero of/tmp/disk2.img bs1M count1024 # 绑定 loop 设备 sudo losetup /dev/loop0 /tmp/disk1.img sudo losetup /dev/loop1 /tmp/disk2.img # 然后就能用 /dev/loop0 /dev/loop1 做 mdadm 练习了这个用法特别适合写实验手册或给团队做内训。不过要记得loop 设备绑定的是文件文件性能会打折仅适合验证功能和命令流程别拿它测试真实性能。5. ZFS 全面实操不只是文件系统是整套存储引擎5.1 先理解 ZFS 的与众不同存储池、校验、快照一次打包ZFS 和传统方案最本质的区别在于它同时扮演了卷管理器、文件系统、RAID 控制器三个角色。所以你不需要先分区、再做 RAID、再建 LVM、再格式化只需要创建存储池然后在池上建数据集就完事了。这个设计带来了几个传统方案没有的优势。首先是写时复制COW机制每次写数据不是覆盖旧数据块而是写到新位置这让快照变得极其廉价且一致。其次是校验和机制ZFS 会为每个数据块保存校验值读数据时验证能发现静默数据损坏——也就是硬件层面没有报错但数据已经坏了的情况。这对传统 RAID 来说是个盲区。但优势也伴随成本。最明显的两条一是内存需求大建议至少按1TB 存储对应 1GB 内存规划二是传统 RAID 的磁盘直接挂载看数据思路在 ZFS 上不适用盘必须导入池才能访问。排查思路要跟着调整。5.2 zpool 创建与 raidz 布局选择别贪心全上 raidz2创建 ZFS 存储池用 zpool 命令虚拟设备vdev类型决定冗余方案# 单盘无冗余 sudo zpool create zpool_test /dev/sdb # 镜像相当于 RAID 1 sudo zpool create zpool_test mirror /dev/sdb /dev/sdc # raidz1相当于 RAID 5允许坏 1 块 sudo zpool create zpool_test raidz1 /dev/sdb /dev/sdc /dev/sdd # raidz2相当于 RAID 6允许坏 2 块 sudo zpool create zpool_test raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde布局选择上我的建议很直接随机读写多的业务用 mirror顺序大文件用 raidz超过 6 块盘的 raidz 单组重建时间太长优先考虑拆成多组 mirror 或 raidz 再 stripe。别贪心全部上一个超大 raidz2盘越多、单块容量越大重建时风险越高而且 ZFS 不支持在线加盘扩 raidz 组虽然新版本支持 raidz expansion但那是较新特性生产环境不一定能用。创建池时还有两个实用参数。一是-f强制创建能忽略盘上的残留文件系统二是-o ashift12强制 4K 扇区对齐。SSD 和 4Kn 盘一定要加ashift12否则性能会难以理解地慢。sudo zpool create -o ashift12 zpool_test mirror /dev/sdb /dev/sdc5.3 zfs 数据集、配额和压缩日常使用率最高的功能创建完存储池通常要在上面建数据集dataset它有点像是目录 配额 权限 压缩设置的合体# 创建数据集 sudo zfs create zpool_test/data # 设置配额限制最多使用 100G sudo zfs set quota100G zpool_test/data # 开启压缩lz4 压缩算法对 CPU 开销极小 sudo zfs set compressionlz4 zpool_test/data # 设置挂载点 sudo zfs set mountpoint/data zpool_test/data这些设置可以随时修改不用像传统文件系统那样重新格式化。lz4 压缩是我必开的实测数据库备份、日志文件这类文本型数据压缩率很可观而且 CPU 开销几乎可以忽略。唯一不建议开的是 dedup去重功能它消耗大量内存而且一旦开启很难关闭除非你内存大得惊人又确实有大量重复数据否则别碰。5.4 ZFS 快照、发送接收备份和恢复演练ZFS 快照和 LVM 快照完全不同它不占用额外固定空间只记录元数据和时间点差异。创建和回滚# 创建快照 sudo zfs snapshot zpool_test/databackup-20240101 # 查看快照 sudo zfs list -t snapshot # 回滚到快照注意会丢失快照之后的改动 sudo zfs rollback zpool_test/databackup-20240101备份到异地用的命令是 zfs send/receive这是 ZFS 最强大的功能之一可以实现增量备份# 第一个完整全量发送 sudo zfs send zpool_test/databackup-20240101 | ssh rootbackup-server zfs receive backup_pool/data # 之后做增量发送比如产生了 backup-20240102 sudo zfs send -i zpool_test/databackup-20240101 zpool_test/databackup-20240102 | ssh rootbackup-server zfs receive backup_pool/data这套逻辑比 rsync 高效得多因为它直接在块级别传差异。我把数据库主机的数据盘用这套方案做异地容灾日常几乎感觉不到备份压力。5.5 zpool 健康检查、scrub 和扩容换盘流程ZFS 的健康检查命令是 scrub它会扫描池里所有数据块的校验和发现静默损坏时尝试用冗余数据修复sudo zpool scrub zpool_test zpool status -v zpool_test # 查看 scrub 进度和结果官方建议每两个月或每月做一次 scrub。如果池里某块盘坏了查看状态和替换# 查看是哪个设备故障 sudo zpool status -v zpool_test # 替换为新的 /dev/sdn sudo zpool replace zpool_test /dev/sdb /dev/sdn替换后 ZFS 会自动重建重建完运行一次 scrub 确认没问题。这里有个实操注意点ZFS 更建议直接使用完整的磁盘如 /dev/sdb而不是分区如 /dev/sdb1因为 ZFS 会自动管理分区和标签。如果你盘上是已有文件系统的旧盘创建池前也要 wipefs 清理否则创建会报错。6. 四个方案放一起怎么排序根据场景硬碰硬对比做了这么多项目的存储设计总结出的选型原则就一句话别让存储方案去适应业务要让业务场景决定方案。我做了个快速对比表对比维度标准分区LVM软 RAIDZFS学习成本低中中高高支持动态扩容不支持支持有限池级扩展数据冗余无无有有快照无有无原生强数据完整性校验无无弱强适合场景系统盘、简单挂载通用服务器扩容可靠性优先大数据、备份、存储服务器具体到我的习惯系统盘/用标准分区或 LVM简单可控不折腾普通业务数据盘用 LVM理由是可以随时扩逻辑清晰数据库、虚拟化存储用软 RAID 10 或 ZFS mirror性能与安全兼顾海量数据备份池、归档存储用 ZFS raidz2靠它抓静默损坏和算高效快照。你可能好奇为什么数据库不用 ZFS raidz 而用 mirror 或者 RAID 10。原因是 raidz 组在随机小写入时会因为写全条带write whole stripe带来额外开销数据库这种随机写密集场景会吃亏。如果坚持用 ZFS建议建多组 mirror 然后 stripe 起来也就是类似 RAID 10 的布局。7. 我的存储管理实操汇总三条经验两个教训最后直接把我这些年用下来最值钱的三条经验写在这里不绕弯子。第一做任何存储变更之前先确认你的文件系统类型再确认操作顺序。这句话听起来是废话但我见过太多次在 xfs 上执行缩容、在 ext4 上扩大完忘记先扩文件系统的错误。把先文件系统、再设备层和xfs 只能扩、ext4 可扩可缩这两句话刻在脑子里能帮你避开 80% 的坑。第二所有生产环境的存储变更都要有回滚方案。所谓回滚方案不是我有备份这么简单而是至少包含如果是 LVM 操作/etc/lvm/backup 下有没有可用的 VG 元数据如果是 ZFS有没有可以回滚到的快照如果是 RAID 操作有没有 spare 盘可用。没有这些我宁愿不操作先建好防御再动手。第三任何方案都不要一个阵列吃到死。乐观点设计有冗余悲观点设计要留余量。我一个很早期的项目里把所有数据放一个 ZFS raidz2 池结果池里两块盘故障后重建期间第三块盘也出现坏道差点全灭。坚持拆池、加热备、定期 scrub这些行为看起来啰嗦但都是关键时候保命的操作。还有一个教训是那次帮同事做 LVM 缩容时因为没做 e2fsck 直接缩了导致文件系统异常、部分目录读不出来。虽然最后靠 fsck 救回来大部分数据但那种项目上线前差点炸穿的心情我再也不想经历第二次。所以我在自己的笔记里永远把这些步骤写在最显眼的位置动文件系统前先 e2fsck、动 ZFS 前先 snap、动 RAID 前先确认 spare。这些实操细节踩过一次坑才真正记住。希望这篇笔记能让你少踩几个相同的坑把 Linux 存储管理这套体系真正串起来用。 
长河君 · 2026/10/15 6:52:48 · 阅读 1.2k Linux存储管理实战：分区、LVM、软RAID与ZFS全解析
1. 先想清楚这四个存储方案到底在解决什么问题先说个判断很多刚接触 Linux 服务器的人容易把磁盘管理简单理解成分区、格式化、挂载。真到了生产环境这套思维根本扛不住事——你总会遇到根分区不够了磁盘阵列里坏了一块盘要备份几十 TB 数据但不想再买一台服务器这类现实问题。这时候如果脑子里只有 fdisk 那三板斧大概率会当场抓瞎。这个项目标题把标准分区、LVM、软件 RAID、ZFS 放在一起不是随便拼凑的四样东西它们其实是 Linux 存储管理的四个递进层次分别解决不同维度的痛点标准分区解决的是如何把一块裸盘变成能用的空间这是地基LVM 解决的是空间不够了怎么办它把物理磁盘抽象成了可以动态调整的逻辑卷软件 RAID 解决的是盘坏了数据会不会丢、读写能不能快一点它用多块盘实现冗余和性能ZFS 则是一个集大成者它把卷管理、文件系统、校验、快照、压缩全部整合在一起思路跟传统方案完全不同。我在实际培训中见过太多人从第一层直接跳到第四层结果把 ZFS 用得像个普通格式化工具一样完全没发挥它的优势。所以这篇实操笔记我按从基础到进阶、从普通到特殊的路线来写每一步都带上我踩过的坑和实测过的命令尽量让你看完就能动手复现。适合读这篇内容的人我大概分三类一是刚入门 Linux 运维、想系统补上存储这块短板的同学二是要从临时处理一下磁盘升级到正经设计一套存储方案的开发者三是已经用过其中一两样、但没成体系串起来的人。如果你属于任何一类这篇应该对你有点用。2. 不补不行的基础标准分区到底怎么理解才算透2.1 分区表类型、对齐和文件系统这些坑别等爆了才学先说分区表。现在主流是 MBR 和 GPT 两种。MBR 最多支持 2TB 和 4 个主分区超过这个容量就得用 GPT。我见过不少同事在给 4TB 盘分区时还在用 fdisk结果 fdisk 默认显示的是 MBR 模式分完区系统只认得出 2TB剩下空间直接蒸发。这事在黑五采购大容量硬盘后特别容易发生。所以建议直接把分区表工具默认思维改成 GPT。在 RHEL 系列、Ubuntu 这些现代发行版上用 parted 或 fdisk 新建分区时直接选 gpt 标签省得后面返工。另一个容易忽略的是分区对齐。老式分区默认从第 63 扇区开始现代硬盘物理扇区是 4096 字节如果逻辑分区起始位置没对齐到 8 的整数倍扇区1MiB 对齐性能会有肉眼可见的下降尤其是跑数据库这类随机读写场景。实际操作里parted 和 fdisk 现在默认都会做对齐但你用脚本或旧工具时一定要手动指定起始位置比如从 2048s 开始。这算是最容易踩的隐形坑。文件系统方面ext4 和 xfs 是 Linux 上最容易遇到的两个。RHEL 系列默认 xfsDebian/Ubuntu 默认 ext4。xfs 胜在稳定性和对大文件、大容量的支持但有一个很大的限制不支持缩容。ext4 则比较灵活可以扩也可以缩。新手如果不清楚这个区别后面 LVM 缩容那一节会直接卡住。2.2 fdisk 实战创建 GPT 分区并挂载完整命令演示我拿一块新加的 1TB 虚拟磁盘做演示设备名假设是 /dev/vdb云主机上常见操作流程如下# 1. 确认磁盘是否已被系统识别 lsblk # 输出里应该能看到 vdb如果没有可能是云平台没挂载先去控制台挂载或执行 rescan-scsi-bus.sh部分系统 # 2. 用 fdisk 进入交互式分区 sudo fdisk /dev/vdb在 fdisk 交互界面里依次输入g # 创建新的 GPT 分区表 n # 新建分区 回车 # 分区号默认即可 回车 # 起始扇区默认会帮你对齐 回车 # 结束扇区默认是磁盘末尾即整个盘一个分区 w # 写入并退出退出后再执行sudo partprobe /dev/vdb让内核重新读取分区表。接着格式化并挂载sudo mkfs.xfs /dev/vdb1 sudo mkdir -p /data sudo mount /dev/vdb1 /data但这里有个新手很容易犯的错误直接 mount 挂载服务器重启后分区不会自动挂载除非写进 /etc/fstab。我的习惯是查看分区的 UUID 再写 fstab而不是直接写设备名因为设备名在重启后可能变化。sudo blkid /dev/vdb1 # 假设输出/dev/vdb1: UUIDxxxx-xxxx TYPExfs # 然后编辑 /etc/fstab 添加一行 # UUIDxxxx-xxxx /data xfs defaults 0 0这里有个验证技巧mount -a执行后没有报错说明 fstab 配置没问题。如果你写错了重启就会直接进入 emergency mode那滋味可不好受。2.3 什么时候你根本不需要分区说出这句话可能会让一些传统运维皱眉但我的实际经验是很多时候整块盘直接格式化挂载性能和维护上都更省心。分区的意义在于隔离、双系统引导、以及某些特殊场景但纯数据盘完全没必要分区。原因很简单如果以后这块盘要扩容云平台加一块更大的盘、然后你用 LVM 把它纳入卷组比在分区表层面搞 resize 要安全得多。另外 SSD 存在预留空间管理分区表多一层反而多一个故障点。在数据盘上我通常用 LVM 替代分区或者干脆裸盘格式化。那标准分区还有什么不可替代的场景系统盘引导/boot 分区、双系统、需要固定大小留给 swap 分区的时候。其他情况我基本都建议走 LVM。3. LVM 扩缩容实操我在扩容现场踩过的坑全记录3.1 LVM 的卷组、物理卷、逻辑卷到底是怎么一个三层结构LVM 的核心思路是把物理磁盘这一层抽象成空间池然后用的时候从池里划。整个过程是三层结构物理卷 PVPhysical Volume、卷组 VGVolume Group、逻辑卷 LVLogical Volume。打个生活化的比方PV 是你家买回来的整袋大米VG 是你把所有大米倒进同一个米缸LV 是你从米缸里舀出来的一碗文件系统是这碗大米煮出来的饭。你随时可以从米缸里再舀一碗也可以把一碗倒回去但前提是米缸里有米——也就是 VG 里有空闲空间。创建 LVM 的手动步骤看起来不复杂但每一步都有讲究。先给盘做 PVsudo pvcreate /dev/vdb1 sudo vgcreate vg_data /dev/vdb1 sudo lvcreate -L 200G -n lv_web vg_data sudo mkfs.xfs /dev/vg_data/lv_web sudo mount /dev/vg_data/lv_web /data这里有两个细节值得注意。一是 PEPhysical Extent大小它是 VG 内部空间分配的最小单位默认 4MiB。如果你只有几个小盘4MiB 没问题但如果你的 VG 要放几百 TB 的超大存储池建议vgcreate -s 16M或更大减少元数据膨胀。第二是 lvcreate 的-L和-l两个参数区别-L接具体大小-l接 PE 数量或百分比比如-l 100%FREE表示用掉卷组里所有剩余空间。3.2 扩容在线的完整步骤xfs 和 ext4 的顺序不能搞反真实场景是这样的某天某应用报磁盘满进服务器一看/data已经 98% 了。我当时的操作就是标准的 LVM 在线扩容流程全程服务不用停。# 1. 查看当前状态 df -h /data lvs vgs # 2. 如果 VG 剩余空间不足先扩 VG # 新加了 /dev/vdc 整盘先建 PV 再并入 VG pvcreate /dev/vdc vgextend vg_data /dev/vdc # 3. 扩展 LV注意 号是增加不带 号是扩展到指定大小 lvextend -L 100G /dev/vg_data/lv_web # 4. 扩展文件系统这步最容易被搞错 xfs_growfs /data # 如果你是 xfs用这个注意不能指定设备名要指定挂载点 resize2fs /dev/vg_data/lv_web # 如果你是 ext4用这个我见过最典型的翻车现场是两个顺序问题第一扩完 LV 忘了扩文件系统命令也执行了但 df 一看还是原大小第二在 xfs 上用了 resize2fs直接报错说不认识这个文件系统。所以一定要先确认你的文件系统类型再选命令。另外一个坑xfs_growfs 需要在挂载状态下、以挂载点为参数执行。如果你因为在维护模式下没法挂载那就用xfs_growfs -d /dev/vg_data/lv_web指定设备这个用法在部分版本上支持但不如挂载点稳。建议还是老老实实挂载上去再扩。3.3 缩容流程ext4 可缩、xfs 不可缩这个结论你怎么记住缩容是 LVM 里最危险的操作没有之一。我强烈建议只在两种情况下做缩容一是测试环境练习二是你确认可以卸载文件系统并且有备份。生产环境里缩容前如果没有做备份一旦搞错中间状态数据可能全没。xfs 不支持缩容这是文件系统层面的硬限制不要在 xfs 的 LV 上尝试lvreduce大概率会损坏文件系统。ext4 可以缩但顺序是反的先缩文件系统再缩 LV。顺序不能反反了就会造成文件系统超出设备边界直接数据损坏。# 假设要把 /dev/vg_data/lv_web 缩到 150G当前 200Gext4 文件系统 # 1. 卸载必须的 umount /data # 2. 检查文件系统e2fsck 不能跳 e2fsck -f /dev/vg_data/lv_web # 3. 先缩文件系统到 150G resize2fs /dev/vg_data/lv_web 150G # 4. 再缩 LV 到 150G注意这里没有 号 lvreduce -L 150G /dev/vg_data/lv_web # 5. 重新挂载验证数据完整性 mount /dev/vg_data/lv_web /data我早期犯过一个错文件系统缩到 150G 后LV 忘记缩然后 VG 里的空闲空间一直没多出来。后来另一个分区告急时才发现几吉空闲空间白白躺在那里。缩容时一定要两步连着做完中途不要切去做别的操作。3.4 LVM 的高级操作快照和元数据恢复关键时刻能救命LVM 快照是个好东西但很多初学者对它抱有错误期待。快照不是备份它是基于写时复制Copy-on-Write机制的一份当时状态的照片。在快照创建之后原始数据发生修改时旧数据会被复制到快照区域所以通过快照可以看到旧版本。创建快照的典型用途是给数据库做备份前的一致点比如给某应用的 LV 做快照然后直接从快照挂载出来跑备份不影响线上数据。lvcreate -L 10G -s -n lv_web_snap /dev/vg_data/lv_web mkdir /snap_mnt mount /dev/vg_data/lv_web_snap /snap_mnt # 备份完成之后卸载并移除快照 umount /snap_mnt lvremove /dev/vg_data/lv_web_snap快照区域的大小要留够如果写时复制的量超过快照空间快照就会失效变成 invalid不能再挂载。所以快照大小至少要预估一下在快照存活期间会有多少数据被修改。另一个值得记住的是 LVM 元数据备份。每次修改 VG 或 LV 时系统都会自动在 /etc/lvm/backup 下生成备份在 /etc/lvm/archive 下生成归档。如果你误删了 LV可以用vgcfgrestore找回来。# 查看卷组信息 vgcfgbackup vg_data # 如果误操作需要恢复先查看备份时间线 ls /etc/lvm/archive/ # 恢复 vgcfgrestore -f /etc/lvm/archive/vg_data_xxxx.vg vg_data这个操作我实际只救过一次但那次就值回票价了。一个同事在生产环境误删了某测试库的 LV当时数据库还没正式启用靠 vgcfgrestore 恢复了 LV 结构数据文件完好无损。4. 软 RAID 全解析mdadm 从建阵列到故障替换的完整笔记4.1 软 RAID 和硬 RAID 怎么选级别别拍脑袋决定软 RAID 用 CPU 和内核 md 模块实现阵列逻辑硬 RAID 依赖专用 RAID 卡。如果你买的是正经服务器有带电池的 RAID 卡硬 RAID 在性能上通常更好但云主机、虚拟机、实验环境这些场景软 RAID 反而是更合适的选择——没有额外硬件成本系统重装后阵列信息也更容易恢复。软 RAID 的常见级别我整理过一张对比表级别最小盘数容量利用率容错能力性能特征适用场景RAID 02100%无读写都提升缓存、临时数据RAID 1250%1 块盘故障读提升、写略降系统盘、数据库日志RAID 53(N-1)/N1 块盘故障读写均衡通用存储RAID 64(N-2)/N2 块盘故障写性能偏低大容量数据RAID 10450%每组1块读写都好数据库、虚拟化我在实际生产中最常用的是 RAID 1 给系统盘、RAID 10 给数据库RAID 5/6 在软 RAID 上要注意重建时的性能开销和故障概率。不建议把所有盘放一个 RAID 5 组盘越多重建时间越长重建期间如果另一块盘也挂了整个阵列就报废了。4.2 用 mdadm 创建 RAID 10 阵列一条命令讲清楚所有参数以四块 1TB 盘 /dev/sdb /dev/sdc /dev/sdd /dev/sde 创建 RAID 10 为例# 首先确保 mdadm 已安装 sudo mdadm --detail-platform # 检查软 RAID 支持 sudo apt install mdadm # Debian/Ubuntu sudo yum install mdadm # RHEL 系列 # 创建 RAID 10注意 metadata 版本用 1.2兼容性和恢复性最好 sudo mdadm --create /dev/md0 --level10 --raid-devices4 \ --metadata1.2 /dev/sdb /dev/sdc /dev/sdd /dev/sde创建命令执行后阵列会进入初始同步状态用/proc/mdstat查看进度cat /proc/mdstat # 输出类似md0 : active raid10 sde[3] sdd[2] sdc[1] sdb[0] # 1515136 blocks super 1.2 level 10, 128k chunk, algorithm 2 [4/4] [UUUU] # [...........] resync 47.8% (742400/1515136) finish2.1min创建期间不要急着格式化使用等 resync 完成后再 mkfs。初始同步期间系统 I/O 会明显变慢正常现象。RAID 10 的布局默认是近布局near还有一种远布局far适合连续读场景。创建时可以加--layoutf2指定但这个参数理解起来比较复杂日常不用动。4.3 阵列的日常维护监控、故障模拟和热备盘阵列创建完不是一劳永逸的日常监控最重要。我习惯把 mdadm 的监控写进 cron 或 systemd timer定期检查阵列状态# 每 10 分钟检查一次有故障就发邮件告警 sudo mdadm --monitor --scan --test -s # 或者直接查看 cat /proc/mdstat sudo mdadm --detail /dev/md0模拟一块盘故障然后替换# 标记 sdc 为故障 sudo mdadm --fail /dev/md0 /dev/sdc # 从阵列中移除 sudo mdadm --remove /dev/md0 /dev/sdc # 插入新盘 sudo mdadm --add /dev/md0 /dev/sdf新盘会自动变成 spare 并开始重建。这个过程里我踩过一个大坑如果新盘上有残留的文件系统签名或 RAID 元数据mdadm 会拒绝添加。解决办法是先清掉签名sudo wipefs -a /dev/sdf然后重新 add。这也是为什么我建议在数组创建前就用 wipefs 把所有盘清干净避免各种莫名的兼容问题。4.4 软 RAID 和 LVM 怎么配合使用顺序很关键很多新人搞不清楚软 RAID 和 LVM 的关系其实它们的合作模式很成熟先用软 RAID 把多块盘合成一个可靠的逻辑盘比如 /dev/md0然后在这个 md 设备上建立 PV、创建 LVM这样做的好处是既能享受 RAID 的冗余又能享受 LVM 的灵活扩缩容。pvcreate /dev/md0 vgcreate vg_raid /dev/md0 lvcreate -L 1.5T -n lv_data vg_raid mkfs.xfs /dev/vg_raid/lv_data mount /dev/vg_raid/lv_data /data但是要注意不要在 LVM 之上再叠加 RAID比如把一个 LV 拿去当 mdadm 的成员盘这就多了一层毫无意义的映射性能反而更差。正确思维是 RAID 在底层LVM 在上层。4.5 用 loop 设备在单机上模拟多盘 RAID练习必备如果你手头只有一台电脑、不想拆机或没有云盘资源loop 设备是最方便的练习方式。原理就是把一个大文件当成一块块磁盘来用# 创建 4 个 1G 的虚拟磁盘文件 dd if/dev/zero of/tmp/disk1.img bs1M count1024 dd if/dev/zero of/tmp/disk2.img bs1M count1024 # 绑定 loop 设备 sudo losetup /dev/loop0 /tmp/disk1.img sudo losetup /dev/loop1 /tmp/disk2.img # 然后就能用 /dev/loop0 /dev/loop1 做 mdadm 练习了这个用法特别适合写实验手册或给团队做内训。不过要记得loop 设备绑定的是文件文件性能会打折仅适合验证功能和命令流程别拿它测试真实性能。5. ZFS 全面实操不只是文件系统是整套存储引擎5.1 先理解 ZFS 的与众不同存储池、校验、快照一次打包ZFS 和传统方案最本质的区别在于它同时扮演了卷管理器、文件系统、RAID 控制器三个角色。所以你不需要先分区、再做 RAID、再建 LVM、再格式化只需要创建存储池然后在池上建数据集就完事了。这个设计带来了几个传统方案没有的优势。首先是写时复制COW机制每次写数据不是覆盖旧数据块而是写到新位置这让快照变得极其廉价且一致。其次是校验和机制ZFS 会为每个数据块保存校验值读数据时验证能发现静默数据损坏——也就是硬件层面没有报错但数据已经坏了的情况。这对传统 RAID 来说是个盲区。但优势也伴随成本。最明显的两条一是内存需求大建议至少按1TB 存储对应 1GB 内存规划二是传统 RAID 的磁盘直接挂载看数据思路在 ZFS 上不适用盘必须导入池才能访问。排查思路要跟着调整。5.2 zpool 创建与 raidz 布局选择别贪心全上 raidz2创建 ZFS 存储池用 zpool 命令虚拟设备vdev类型决定冗余方案# 单盘无冗余 sudo zpool create zpool_test /dev/sdb # 镜像相当于 RAID 1 sudo zpool create zpool_test mirror /dev/sdb /dev/sdc # raidz1相当于 RAID 5允许坏 1 块 sudo zpool create zpool_test raidz1 /dev/sdb /dev/sdc /dev/sdd # raidz2相当于 RAID 6允许坏 2 块 sudo zpool create zpool_test raidz2 /dev/sdb /dev/sdc /dev/sdd /dev/sde布局选择上我的建议很直接随机读写多的业务用 mirror顺序大文件用 raidz超过 6 块盘的 raidz 单组重建时间太长优先考虑拆成多组 mirror 或 raidz 再 stripe。别贪心全部上一个超大 raidz2盘越多、单块容量越大重建时风险越高而且 ZFS 不支持在线加盘扩 raidz 组虽然新版本支持 raidz expansion但那是较新特性生产环境不一定能用。创建池时还有两个实用参数。一是-f强制创建能忽略盘上的残留文件系统二是-o ashift12强制 4K 扇区对齐。SSD 和 4Kn 盘一定要加ashift12否则性能会难以理解地慢。sudo zpool create -o ashift12 zpool_test mirror /dev/sdb /dev/sdc5.3 zfs 数据集、配额和压缩日常使用率最高的功能创建完存储池通常要在上面建数据集dataset它有点像是目录 配额 权限 压缩设置的合体# 创建数据集 sudo zfs create zpool_test/data # 设置配额限制最多使用 100G sudo zfs set quota100G zpool_test/data # 开启压缩lz4 压缩算法对 CPU 开销极小 sudo zfs set compressionlz4 zpool_test/data # 设置挂载点 sudo zfs set mountpoint/data zpool_test/data这些设置可以随时修改不用像传统文件系统那样重新格式化。lz4 压缩是我必开的实测数据库备份、日志文件这类文本型数据压缩率很可观而且 CPU 开销几乎可以忽略。唯一不建议开的是 dedup去重功能它消耗大量内存而且一旦开启很难关闭除非你内存大得惊人又确实有大量重复数据否则别碰。5.4 ZFS 快照、发送接收备份和恢复演练ZFS 快照和 LVM 快照完全不同它不占用额外固定空间只记录元数据和时间点差异。创建和回滚# 创建快照 sudo zfs snapshot zpool_test/databackup-20240101 # 查看快照 sudo zfs list -t snapshot # 回滚到快照注意会丢失快照之后的改动 sudo zfs rollback zpool_test/databackup-20240101备份到异地用的命令是 zfs send/receive这是 ZFS 最强大的功能之一可以实现增量备份# 第一个完整全量发送 sudo zfs send zpool_test/databackup-20240101 | ssh rootbackup-server zfs receive backup_pool/data # 之后做增量发送比如产生了 backup-20240102 sudo zfs send -i zpool_test/databackup-20240101 zpool_test/databackup-20240102 | ssh rootbackup-server zfs receive backup_pool/data这套逻辑比 rsync 高效得多因为它直接在块级别传差异。我把数据库主机的数据盘用这套方案做异地容灾日常几乎感觉不到备份压力。5.5 zpool 健康检查、scrub 和扩容换盘流程ZFS 的健康检查命令是 scrub它会扫描池里所有数据块的校验和发现静默损坏时尝试用冗余数据修复sudo zpool scrub zpool_test zpool status -v zpool_test # 查看 scrub 进度和结果官方建议每两个月或每月做一次 scrub。如果池里某块盘坏了查看状态和替换# 查看是哪个设备故障 sudo zpool status -v zpool_test # 替换为新的 /dev/sdn sudo zpool replace zpool_test /dev/sdb /dev/sdn替换后 ZFS 会自动重建重建完运行一次 scrub 确认没问题。这里有个实操注意点ZFS 更建议直接使用完整的磁盘如 /dev/sdb而不是分区如 /dev/sdb1因为 ZFS 会自动管理分区和标签。如果你盘上是已有文件系统的旧盘创建池前也要 wipefs 清理否则创建会报错。6. 四个方案放一起怎么排序根据场景硬碰硬对比做了这么多项目的存储设计总结出的选型原则就一句话别让存储方案去适应业务要让业务场景决定方案。我做了个快速对比表对比维度标准分区LVM软 RAIDZFS学习成本低中中高高支持动态扩容不支持支持有限池级扩展数据冗余无无有有快照无有无原生强数据完整性校验无无弱强适合场景系统盘、简单挂载通用服务器扩容可靠性优先大数据、备份、存储服务器具体到我的习惯系统盘/用标准分区或 LVM简单可控不折腾普通业务数据盘用 LVM理由是可以随时扩逻辑清晰数据库、虚拟化存储用软 RAID 10 或 ZFS mirror性能与安全兼顾海量数据备份池、归档存储用 ZFS raidz2靠它抓静默损坏和算高效快照。你可能好奇为什么数据库不用 ZFS raidz 而用 mirror 或者 RAID 10。原因是 raidz 组在随机小写入时会因为写全条带write whole stripe带来额外开销数据库这种随机写密集场景会吃亏。如果坚持用 ZFS建议建多组 mirror 然后 stripe 起来也就是类似 RAID 10 的布局。7. 我的存储管理实操汇总三条经验两个教训最后直接把我这些年用下来最值钱的三条经验写在这里不绕弯子。第一做任何存储变更之前先确认你的文件系统类型再确认操作顺序。这句话听起来是废话但我见过太多次在 xfs 上执行缩容、在 ext4 上扩大完忘记先扩文件系统的错误。把先文件系统、再设备层和xfs 只能扩、ext4 可扩可缩这两句话刻在脑子里能帮你避开 80% 的坑。第二所有生产环境的存储变更都要有回滚方案。所谓回滚方案不是我有备份这么简单而是至少包含如果是 LVM 操作/etc/lvm/backup 下有没有可用的 VG 元数据如果是 ZFS有没有可以回滚到的快照如果是 RAID 操作有没有 spare 盘可用。没有这些我宁愿不操作先建好防御再动手。第三任何方案都不要一个阵列吃到死。乐观点设计有冗余悲观点设计要留余量。我一个很早期的项目里把所有数据放一个 ZFS raidz2 池结果池里两块盘故障后重建期间第三块盘也出现坏道差点全灭。坚持拆池、加热备、定期 scrub这些行为看起来啰嗦但都是关键时候保命的操作。还有一个教训是那次帮同事做 LVM 缩容时因为没做 e2fsck 直接缩了导致文件系统异常、部分目录读不出来。虽然最后靠 fsck 救回来大部分数据但那种项目上线前差点炸穿的心情我再也不想经历第二次。所以我在自己的笔记里永远把这些步骤写在最显眼的位置动文件系统前先 e2fsck、动 ZFS 前先 snap、动 RAID 前先确认 spare。这些实操细节踩过一次坑才真正记住。希望这篇笔记能让你少踩几个相同的坑把 Linux 存储管理这套体系真正串起来用。