磁盘格式化和LVM挂载1. 为什么数据盘必须格式化之后才能用1.1 从一块裸盘说起你拿到手的盘到底是什么状态很多刚接触服务器运维的朋友第一次在自己电脑上装Linux或者买了一台云服务器之后都会遇到一个非常尴尬的情况明明在控制台看到数据盘已经挂上了结果登录系统一查df -h里根本看不到这块盘或者看到了一个设备名却完全没法写入数据。这个问题的根源在于物理磁盘或者云盘在被操作系统识别之后只是一块白纸没有任何文件系统在上面。没有文件系统操作系统就不知道如何去组织文件、目录、权限这些元数据自然也就无法正常使用。我见过太多初学者在这件事上栽跟头。他们拿着fdisk -l看到/dev/vdb这样的设备名然后直接mount /dev/vdb /data结果报错mount: /dev/vdb is not a valid block device或者you must specify the filesystem type。这不是因为命令敲错了而是因为这块盘压根还没准备好。对于一块全新的数据盘标准流程应该是分区可选→ 格式化创建文件系统→ 挂载mount→ 写入开机自动挂载配置。其中分区可以做也可以不做如果你不需要把一块大盘拆成好几个区域用直接整块盘格式化反而更省事。1.2 格式化到底在做什么文件系统是把数据编排起来的规则格式化这个动作本质上是在磁盘上写入一套文件系统结构。不同的文件系统就像不同的仓库管理方案有的适合小文件存取有的适合超大文件顺序读写有的对损坏容错率更高。以最常见的两种文件系统为例ext4Linux传统默认文件系统稳定可靠支持日志journaling系统突然断电后能快速恢复一致性。对于大多数没有特殊性能要求的业务场景ext4都是稳妥之选。xfsRHEL/CentOS 7及以后的默认文件系统优势体现在对超大文件和大容量卷的扩展能力上尤其是支持在线扩容不需要卸载分区就能扩大空间这一点在配合LVM使用的时候非常顺手。选文件系统我个人的习惯是新项目优先xfs老环境延用ext4。因为xfs对超大规模存储的处理更好而且在线扩充分区的能力在运维场景里特别实用ext4则胜在兼容性和成熟度几乎没有坑。格式化的命令很简洁# 创建ext4文件系统 mkfs.ext4 /dev/vdb # 创建xfs文件系统 mkfs.xfs /dev/vdb这条命令一执行磁盘上的数据就会被文件系统的元数据覆盖。所以一个老生常谈却永远有人踩的坑就是格式化之前一定要确认设备名没有搞错不然一个手滑把系统盘给格式化了后果不堪设想。1.3 分区的意义什么时候分区什么时候整块盘直接用分区这个概念简单理解就是把一块物理磁盘划成好几个逻辑区域。每块区域可以单独格式化、单独挂载、单独管理。实际操作中我见过不少运维老手在数据盘上做分区的场景其实真正常见的也就这几种磁盘本身非常巨大比如10T、20T需要拆成几个逻辑卷分配给不同业务使用有特殊需求比如启动分区、BIOS boot分区这种系统级用途配合LVM时需要把物理磁盘先标记为LVM分区类型。如果你只是要把一整块数据盘挂载到某个目录比如把100G的云盘整个挂到/data那完全不需要分区直接格式化然后挂载就好了。在Linux中不带分区表直接用整块盘性能和稳定性没有任何问题反而能少处理一层分区表的复杂度。一个常见的误区是很多人觉得分区更规整、更专业。但当你只有一个数据盘、一个挂载点的时候分区只是给自己多增加了一层无意义的抽象。保持简单才是运维的第一原则。2. LVM存在的意义传统分区做不到的在线扩容2.1 传统分区的痛点空间不够了怎么办假设你的数据盘是100G直接格式化成ext4之后挂到/data。用了一年业务涨了100G满了。这时候你怎么扩容麻烦来了。传统分区方案下扩容有两条路如果这块盘原本还有未分配的空间可以扩展分区但前提是扩容的空间必须紧挨着原分区而且分区表调整的过程通常需要卸载分区才能操作线上业务根本经不起这样折腾如果整个物理盘都满了那就只能新买一块更大的盘把数据拷贝过去重新挂载。拷贝几百GB甚至几TB数据的时间成本想想都头疼。这就是LVM逻辑卷管理存在的真正理由。LVM把底层的物理磁盘抽象成一个空间池你从池子里切出任意大小的逻辑卷分配给业务使用。这个池子可以随时加入新的物理磁盘来扩大池子里的逻辑卷也可以在线调整大小——不需要卸载不需要停机。2.2 LVM的三层架构PV、VG、LV学习LVM最核心的一点是记住它把传统分区表的磁盘→分区变成了物理卷→卷组→逻辑卷三层结构LVM组件简称作用类比物理卷PV把物理磁盘或分区初始化为LVM可管理的单元一块块实体的建材卷组VG把多个PV聚合起来形成一个统一的存储池仓库的总面积逻辑卷LV从VG中划分出来的区块格式化后直接挂载使用仓库里划分出的每个隔间整个操作流程就是先把磁盘做成PV再把PV加入VG然后从VG里切出LV最后格式化并挂载LV。这三层的价值一句话就能概括PV负责买地VG负责圈地LV负责分地。买的新地随时可以并入圈地范围圈地内的隔间可以随意扩大缩小而不需要动隔板本身。2.3 什么时候用LVM什么时候用裸分区LVM虽然强大但也不是非用不可。我的判断标准是这样的需要灵活扩容的多数据盘场景强烈建议上LVM。比如一台服务器上挂了多块数据盘业务数据不断增长未来可能随时加盘扩容LVM能让你用最小的成本完成空间扩展。单块盘固定用途、确定不会扩容的场景裸分区完全够用。比如一块SATA盘专门存冷备份数据容量需求几年内都不会变没必要引入LVM的额外复杂度。还有一个不能忽视的因素是内核和引导的兼容性。根分区/不要用LVM尤其是在涉及系统启动、引导修复这类场景时LVM会多一层逻辑排查起来复杂得多。数据分区用LVM是完全没问题的。3. 从零开始物理盘格式化、LVM创建与挂载全流程3.1 环境确认先看清系统里到底有哪些磁盘动手之前一定要做完整的环境勘察。记住一句话设备名看一下不会少块肉不看出了问题体重直接翻倍。登录服务器后先用这几个命令把所有磁盘信息摸清楚# 列出系统识别到的所有磁盘 lsblk # 查看磁盘详细信息和分区表 fdisk -l # 查看已有的LVM物理卷 pvslsblk的输出非常直观树状结构一下就能看出哪块盘挂在哪哪块盘还是裸的。比如你看到NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 40G 0 disk └─vda1 252:1 0 40G 0 part / vdb 252:16 0 200G 0 diskvdb就是一块200G的裸盘没有任何分区也没有挂载点。这就是我们这篇文章要处理的对象。3.2 实操开始从裸盘到LVM的完整命令序列下面这组命令是我在实际项目里最常用的一套标准流程以一块200G数据盘/dev/vdb为例挂载目标目录为/data。# 第一步创建PV物理卷 pvcreate /dev/vdb # 查看PV是否创建成功 pvs # 第二步创建VG卷组名字定为vgdata vgcreate vgdata /dev/vdb # 查看VG状态能看到总大小和剩余空间 vgs # 第三步从vgdata中切出一个100G的LV名字定为lvdata lvcreate -L 100G -n lvdata vgdata # 查看LV信息 lvs # 第四步格式化LV mkfs.xfs /dev/vgdata/lvdata # 第五步挂载 mkdir -p /data mount /dev/vgdata/lvdata /data # 确认挂载成功 df -h /data执行完这组命令你已经完成了一次标准的LVM创建挂载流程。整个过程中每一步都有对应的查询命令pvs、vgs、lvs每执行一个关键步骤都去查一下状态这是防止出错的最好习惯。一个细节值得注意lvcreate命令给出的LV设备路径是什么是/dev/vgdata/lvdata。这个路径在LVM中是一个软链接如果VG和LV名字起得比较随意这个路径其实不太好记。所以给VG和LV起名字的时候尽量用有业务含义的单词比如vgdata、lvdata或者vgbackup、lvbackup这种一眼就能看出用途。3.3 一步到位自动化脚本版本的完整流程对于重复性很高的初始化流程每次手动敲命令容易漏步骤我习惯把整段流程写成一个脚本带着参数跑。#!/bin/bash # init_lvm.sh - 初始化数据盘并创建LVM挂载 # 用法: ./init_lvm.sh /dev/vdb vgdata lvdata /data DISK$1 VGNAME$2 LVNAME$3 MOUNT_POINT$4 # 安全检查确认设备存在且未被使用 if ! lsblk $DISK /dev/null 21; then echo 错误设备 $DISK 不存在 exit 1 fi # 确认设备未被格式化或挂载 if blkid $DISK /dev/null 21; then echo 警告$DISK 上已存在文件系统脚本退出 echo 如确需格式化请手动执行 mkfs 命令 exit 1 fi # 创建PV、VG、LV pvcreate $DISK vgcreate $VGNAME $DISK lvcreate -l 100%FREE -n $LVNAME $VGNAME # 格式化LV为xfs mkfs.xfs /dev/$VGNAME/$LVNAME # 创建挂载点并挂载 mkdir -p $MOUNT_POINT mount /dev/$VGNAME/$LVNAME $MOUNT_POINT # 写入开机自动挂载 UUID$(blkid -s UUID -o value /dev/$VGNAME/$LVNAME) echo UUID$UUID $MOUNT_POINT xfs defaults 0 0 /etc/fstab echo LVM挂载完成$DISK - $MOUNT_POINT df -h $MOUNT_POINT这里我把LV的大小直接设为100%FREE也就是把VG里所有空间都分配给这个LV。多数情况下数据盘只有一个逻辑卷需求这条写法最简单实用。脚本里值得留意的几个安全设计一是用lsblk确认设备存在二是用blkid确认设备上还没有文件系统这两道检查能拦住90%的误操作场景。在此基础上你还可以加一道确认提示要求操作者手动输入YES才继续不过那已经属于公司运维规范层面的事了。4. LVM空间扩充实践从PV扩容到LV扩容的完整链路4.1 场景展开磁盘使用率告警之后的应急处理LVM挂载完成之后真正的考验在后面。假设半年后运营发来告警说/data使用率已经92%你登录检查# 查看挂载点使用率 df -h /data # 查看VG剩余空间 vgs如果VG里还有剩余空间那扩容LV就特别简单# 将lvdata扩大50G lvextend -L 50G /dev/vgdata/lvdata # 扩容文件系统xfs在线扩容 xfs_growfs /data注意文件系统类型不同扩容命令完全不同。这里是最容易踩坑的地方。xfs用xfs_growfs /data指定挂载点ext4用resize2fs /dev/vgdata/lvdata指定设备路径。命令用错直接报错xfs_growfs: /dev/vgdata/lvdata is not a mounted XFS filesystem很多人就是在这里卡壳的。xfs的扩容命令参数在RHEL/CentOS系文档里写的是挂载点路径而ext4的resize2fs要的是设备路径。这两个工具的设计哲学就不一样只能硬记。4.2 VG空间不够把新磁盘加进卷组上面那种情况如果vgs显示VG里已经没有剩余空间了你就需要把一块全新的物理磁盘加入卷组来扩容。假设云服务商新挂载了一块300G的盘设备名/dev/vdc# 创建新PV pvcreate /dev/vdc # 把新PV扩展到已有的vgdata卷组 vgextend vgdata /dev/vdc # 查看VG空间是否增加 vgs # 现在VG里有剩余空间了可以扩容LV lvextend -L 200G /dev/vgdata/lvdata # 文件系统在线扩容 xfs_growfs /data这样一个完整的三层扩容链路就走通了新磁盘 → PV → VG → LV → 文件系统。整个过程业务完全无感知/data目录下的服务一直在运行这就是LVM相对于传统分区最大的优势——在线热扩容。4.3 缩容操作能不做就不做要做先卸载讲完扩容必须提一嘴缩容。LVM的LV缩容在xfs上是完全不支持的如果要缩容xfs的逻辑卷唯一的路径是备份数据、删除LV、重建LV、恢复数据。ext4倒是支持缩容但也必须先卸载文件系统才能操作而且缩容过程一旦中断数据损坏风险很高。我的建议是生产环境永远不要做缩容。空间不够了就加盘加盘是你唯一的、也是最安全的扩容方式。缩容带来的风险远比省下的那点空间值得多运维人员一定要有这样的风险意识。5. 开机自动挂载/etc/fstab配置与常见坑5.1 fstab的字段含义不光要能挂上还要挂得稳mount命令只是临时挂载重启之后就不生效了。要让系统开机自动挂载需要写进/etc/fstab。fstab每一行有6个字段空格分隔一个都不能少设备标识 挂载点 文件系统类型 挂载选项 dump备份标志 fsck检查顺序以我们前面创建的LVM逻辑卷为例最靠谱的写法是用UUID来标识设备# 获取LV的UUID blkid /dev/vgdata/lvdata # 输出示例 /dev/vgdata/lvdata: UUIDa1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx TYPExfs # 然后编辑 /etc/fstab追加如下内容 UUIDa1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults 0 0这里我非常强烈地建议不要直接写/dev/vgdata/lvdata这种设备路径原因有两个LVM的设备路径确实相对稳定但有些环境下内核枚举设备名的顺序变了设备路径可能对不上UUID是文件系统级的唯一标识不管设备名怎么变只要文件系统没变UUID就不会变。5.2 挂载参数的选择defaults、noatime与性能取舍fstab里的挂载参数很多人一直用defaults。在SSD时代noatime绝对值得加上。atime是访问时间的意思每次读取文件时系统都会更新这个时间戳。但绝大多数业务根本不会用这个时间戳白白增加了很多磁盘写入。# 推荐的数据盘挂载参数 UUIDa1b2c3d4-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults,noatime 0 0加上noatime之后读取文件不再更新时间戳IO压力会明显下降。对于高并发的文件和图片读写业务这个参数的收益非常直接。还有一个比较常见的选项是nodiratime不更新目录的访问时间如果加了noatime目录时间也已经涵盖了不需要重复加。5.3 fstab写错之后的救场技巧fstab写错是Linux运维的经典翻车名场面改完fstab习惯性执行mount -a结果直接报错或者干脆重启之后系统挂在登录界面进不去。真实的处理过程是这样的重启后系统报错提示无法挂载某个文件系统此时会进入emergency模式或者让你输入root密码维护用mount -o remount,rw /把根分区重新挂载成可写状态编辑/etc/fstab把刚才写错的行注释掉或者修正重新执行mount -a验证没问题再重启。对付fstab错误我实践下来的核心建议是每次修改fstab之后先执行mount -a验证一遍。这个命令会按fstab的配置把未挂载的内容全部挂载一遍如果有错误会立刻报出来给你及时修复的机会不至于等到重启才被反杀。6. 实际项目中LVM挂载最容易踩的坑6.1 设备名漂移你以为是next其实是另一个在云服务器或者有多块盘的物理机上设备名并不能100%保证每次开机都一样。今天/dev/vdb是数据盘可能某次重启后数据盘变成了/dev/vdc原来的/dev/vdb变成了别的盘。这就是为什么之前的整个过程里我反复强调用UUID而不是设备路径来写fstab。LVM在这方面还有个额外buff如果你用/dev/vgdata/lvdata这种路径LVM自己会通过设备映射器device mapper保证逻辑卷路径的稳定性只要VG名和LV名不变路径基本不会变。但这并不代表你可以随意用条件允许时还是UUID最稳。一种我实践中的验证习惯是第一次挂载完成后用findmnt /data确认挂载来源再用blkid记下UUID两处核对无误之后才写入fstab。6.2 格式化用错设备名的灾难级事故与预防每次想到这个坑我都想起某位前同事的教训。他当时给一台新服务器做数据盘初始化服务器上同时挂着系统盘和数据盘设备名一个vda一个vdb结果命令里的设备名写反了mkfs.ext4 /dev/vda直接把手上的系统盘给格式化了。事后盘点整台服务器的所有配置、应用、数据库全没了幸好有备份但还是花了大半天才恢复。这是一次典型的一个字母差之千里的事故。预防措施其实很简单执行任何写操作格式化、pvcreate前先lsblk确认设备名和挂载状态用lsblk -o NAME,SIZE,MODEL,SERIAL核对磁盘序列号确保物理上与设备名对应坚决不执行mkfs这种破坏性命令除非你有100%的把握。我自己的习惯是拿一张纸或者用shell变量把系统盘和数据盘的设备名记下来命令里只用变量替代DATADISK/dev/vdb SYSTEMDISK/dev/vda6.3 剩余空间不等于可用空间xfs在线扩容后的验证扩容操作成功后很多人真的会原地愣住。执行完了xfs_growfs /data但df -h /data显示空间没变。这个现象在xfs上有一种典型成因你扩容了LV但没有执行xfs_growfs或者执行了但参数写错。lvextend只扩展了LVM层的逻辑卷大小文件系统层的元数据还维持原样两者必须配合使用。# 正确顺序先扩LV再扩文件系统 lvextend -L 50G /dev/vgdata/lvdata xfs_growfs /data # 验证 df -h /data如果你发现df -h显示的空间仍然没有变化优先怀疑xfs_growfs没有真正执行成功。用xfs_info /data查看文件系统的实际容量就能确认到底扩没扩上。6.4 卸载时device is busy的处理要卸载一个正在被业务使用的挂载点系统会报target is busy。这时候需要先找出谁占用了这个挂载点# 找出占用挂载点的进程 lsof /data # 或者使用fuser fuser -m /data找到占用进程后是停进程再卸载还是直接强制卸载取决于业务容忍度# 强制卸载生产环境慎用 umount -l /data-l参数是懒卸载效果是先将挂载点从目录树中摘除等内核里的引用释放后真正卸载。看上去很酷但业务进程如果还在读写可能造成数据不一致。我的建议是数据盘卸载尽量先停业务、再卸载宁可多等几秒不要贪图快。7. LVM进阶配置与我的个人心得7.1 快照功能给数据上一道免费保险LVM最有价值的隐藏功能之一就是快照snapshot。它可以在不给业务停机的前提下将一个逻辑卷在某个时间点的状态冻结出来。# 创建lvdata逻辑卷的快照快照大小为20G lvcreate -L 20G -s -n lvdata_snap /dev/vgdata/lvdata # 挂载快照查看历史数据 mkdir -p /mnt/snap mount /dev/vgdata/lvdata_snap /mnt/snap快照的工作原理是基于写时复制COW创建快照时并不复制数据只有当原卷发生数据变更时被变更的数据块才写入快照区。所以快照的初始空间占用几乎是0后续占用取决于原卷的写入频率和数据量。快照不能替代备份因为快照和原卷都在同一块物理磁盘上物理盘挂了快照也没了。但它非常适合做升级前的保驾护航在跑数据库迁移、系统升级、批量改配置这类高风险操作前打一个快照出问题了直接回滚省下大量重装的时间成本。7.2 多磁盘合并成一个卷组打破单盘容量天花板LVM另一个让我离不开的功能是把多块物理盘合并成一个超大空间。比如有两块500G的数据盘单独使用就是两个500G的最大容量用LVM把它们放进同一个VGLV就能到达接近1T的空间。pvcreate /dev/vdb /dev/vdc vgcreate vgdata /dev/vdb /dev/vdc lvcreate -l 100%FREE -n lvdata vgdata mkfs.xfs /dev/vgdata/lvdata数据会由LVM的条带化机制分布在多块物理盘上。好处不言而喻容量上限大幅提升还能获得一定的并行IO吞吐增益。代价则是其中任何一块物理盘故障整个逻辑卷的数据都可能不可用。所以多盘合并之后数据安全级别要考虑得更周全该做备份就做备份。7.3 一些写在最后的心得LVM挂载这套流程本质上是一种管理思维把底层的物理资源抽象成可灵活调度的逻辑资源。接触初期会觉得多了一层东西很麻烦但真正遇到扩容需求时才知道这层抽象帮你挡掉了多少灾难。结合我自己从裸分区一路走过来踩过的坑最想分享的经验是这三条第一所有破坏性操作都要确认设备名格式化、pvcreate、lvremove之前一律先lsblk这是运维人的底线操作。第二扩容要按顺序执行且验证结果LV层和文件系统层必须同时处理只做一半就是看起来没变化的假成功。第三fstab里全用UUID不要用设备路径。一次重启后设备名漂移就能让你深刻理解什么叫省事一时爽排查火葬场。磁盘格式化和LVM挂载这个主题技术本身不难真正难的是在每一台服务器上稳定复现同一套高质量的流程习惯。希望这篇文章能帮你把基础打牢后续无论环境多复杂底层这套逻辑都不会变。