干运维这行我处理过最多的告警不是CPU爆了、不是内存不够而是磁盘满了。尤其那些多年前部署的服务器当初分区时想当然地把 /data 分了500G两年后业务一膨胀直接傻眼。传统分区方案想扩一个分区的难度不亚于重新部署业务。但如果当初就用LVM逻辑卷管理后期扩容基本就是一条命令的事。这篇文章我结合自己在磁盘管理和LVM上的实操经验把概念、命令、扩容缩容、云环境下的坑一次性说清楚。适合刚接手服务器的运维新人也适合正在为根分区扩容发愁的老手。1. 为什么我劝你先搞懂LVM再碰磁盘分区1.1 传统分区方案的三个硬伤大多数人第一次接触Linux磁盘管理学的都是fdisk直接划分分区/dev/sda1、/dev/sda2格式化之后挂载到目录。这套方案在小规模、一次性部署的场景下没什么问题但一旦业务跑起来缺点会逐渐变成灾难。第一个硬伤是分区大小在创建那一刻就固定了。你给了根分区50G将来系统更新、/var日志增长、/home放了一堆大文件50G不够了怎么办传统做法是加一块新盘挂载到另外一个目录然后把数据拷贝过去再改业务路径。整个流程涉及业务停摆、数据迁移、软链接处理说实话每次做这种事我都想把当初分区的人拉来聊聊。第二个硬伤是单个分区无法跨越物理磁盘。比如你有两块2TB的盘想做一个4TB的统一目录放监控数据传统分区根本做不到。你只能在其中一块盘上划2TB出来剩下那2TB要么闲着要么拆成另一个目录数据管理变得破碎。第三个硬伤是操作风险高。用fdisk对在线系统做分区调整动一下就是数据损坏级别的事故。而且普通分区方案没有快照能力想做一个临时备份点再去升级应用往往得借助额外的备份工具非常不灵活。1.2 LVM到底做了什么LVMLogical Volume Manager逻辑卷管理的核心思路是把物理磁盘和你看到的文件系统之间加了一个抽象层。它先把物理磁盘的某个分区或整块盘封装成一个PV物理卷再把多个PV合并成一个VG卷组最后从VG里切出LV逻辑卷给你格式化挂载。这个抽象层带来三个传统分区方案无法企及的收益第一容量池化。多块闲置硬盘可以合成一个资源池需要多大逻辑卷就从池里划多大第二在线扩容。VG里的空间不够时往池子里加一块新盘就行LV可以跟着变大文件系统在线同步扩展业务无感第三快照特性。LV级别可以做写时复制快照用于备份和测试环境极其方便。这里说句实在话LVM在技术上不是最新的东西上世纪90年代Linux社区就在弄了Red Hat、CentOS、Ubuntu Server都默认支持。但它直到今天仍然是生产环境里最靠谱的磁盘管理方案之一尤其是根分区和日志目录天然适合LVM来管。1.3 什么时候果断用LVM什么时候可以缓一缓不是所有服务器都非用LVM不可我给自己定了个判断标准数据库数据目录、日志目录、文件服务器共享目录必须用LVM方便后期扩容。系统根分区建议用LVM。现在很多云服务器的默认镜像就是LVM原因就是后期不用重装。一台只跑临时静态文件的测试机磁盘大小固定且业务不会再增长用普通分区也行省心。高IOPS的核心交易库LVM本身损耗极小但务必压测确认不能无脑套模板。2. 磁盘管理基本功先学会看清这台机器的存储家底2.1 常用的查看命令别再只会df -h拿到一台服务器第一步永远是看清家底。很多人上来就df -h容量看了个大概但底层是什么盘、哪些分区属于哪个设备根本无从得知。我一般按顺序执行这组命令# 查看块设备树状结构能显示磁盘和分区、挂载点、设备类型 lsblk # 查看文件系统使用率看业务压力最直观 df -hT # 查看裸设备/分区的精确信息没挂载的盘也能看到 fdisk -l # 查看分区的UUID、文件系统类型、LVM成员标签 blkid这几条命令各有侧重。lsblk用于快速理解哪块盘挂在哪个目录df -hT看的是文件系统层面的使用率和类型fdisk -l适合确认新接入的裸盘是否被内核识别blkid则是做自动挂载、判断LVM成员时会用到。2.2 快速识别系统盘和数据盘服务器里多块盘并存时最大的风险是搞错对象。我曾经见过有人把系统盘当成数据盘重新分区后果可想而知。我的识别方法很简单lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,FSTYPE如果某个设备下面带着/boot挂载点那基本就是系统盘。在云环境里系统盘通常是/dev/vda或/dev/sda数据盘按顺序由/dev/vdb、/dev/vdc排下去。保险起见还可以查/sys/block或看云控制台的磁盘ID避免本地盘和云盘混淆。另外判断一个磁盘是不是已经被LVM接管看FSTYPE列。PV的FSTYPE会显示LVM2_memberVG和LV则不会直接出现在lsblk的分区层里需要配合pvs、vgs、lvs三条命令来看。2.3 别忘了看磁盘健康状态磁盘管理不只是管容量还要管故障率。我养成的习惯是定期跑一下smartctl查SMART信息尤其是运行超过三年的老盘smartctl -a /dev/sdb | grep -E Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error重映射扇区数持续增长、待纠正扇区数不为零都是盘要坏的预警。另外iostat -x 1可以看忙碌度和等待时间如果某块盘%util长期100%那业务慢的根源不在CPU而在I/O瓶颈这种时候就算LVM扩容也解决不了得考虑换更高性能的磁盘了。3. LVM核心概念拆解PV、VG、LV、PE一篇文章讲透3.1 四个概念用仓库类比一次记住LVM里有一堆缩写刚接触时很容易懵。我用一个仓库模型来理解实践下来讲课和培训效果都不错PVPhysical Volume物理卷相当于一块一块进货的物料来自某个实际磁盘分区或整块盘。VGVolume Group卷组相当于一个大仓库。多个PV可以放进同一个仓库仓库的容量就是所有PV容量的总和。LVLogical Volume逻辑卷相当于在仓库里用隔板划出的一个个独立储物间每个储物间可以单独格式化和挂载。PEPhysical Extent物理扩展块相当于仓库里的标准货位默认4MiB一个。LV和PV的映射本质就是储物间占用了哪些货位。了解了这个模型再看LVM的命令就顺理成章pvcreate是把盘变成物料vgcreate是建仓库lvcreate是划隔间vgextend是扩仓库lvextend是扩隔间。3.2 数据从应用到底层硬盘的映射路径平时你写文件时数据经过了这样一个链路进程 - 文件系统ext4/xfs - LV - VG中的PV - 磁盘扇区。这里的核心是LE和PE的对应关系。每个LV被划分成若干个LELogical Extent逻辑扩展块而VG中的每个PV被划分成若干个PE。逻辑上LV的每个LE会映射到一个PE。之所以设计PE这层是为了让VG内的空闲空间可以被任意分配新加入的盘上PE可以补到任何LV的尾部这样扩容才灵活。有个实际经验要说一下默认PE大小是4MiB绝大多数场景不用调整。但如果做数据库高并发写入建议在创建VG时用vgcreate --physicalextentsize 16M或者更大的PE大小减少元数据映射的开销。这个属于调优手段默认情况不用纠结。3.3 LVM设备的路径规则创建完LV后你会得到两种路径。以VG名为vg_data、LV名为lv_data为例# 经典路径 /dev/vg_data/lv_data # 通过设备映射器访问的路径 /dev/mapper/vg_data-lv_data这两种路径指向同一个设备二者等价。但在fstab里写挂载项时我更推荐用UUID去做。因为Linux重启后设备识别顺序可能变化设备路径可能不固定UUID则是稳定的。拿到UUID的方式就是上面提到的blkidblkid /dev/vg_data/lv_data之后在/etc/fstab里写一行UUIDxxxx /data ext4 defaults 0 0就稳了。4. 动手实操从裸盘到可用的LVM卷4.1 分区并标记为LVM类型假设业务新接入了两块300GB的盘/dev/sdb和/dev/sdc。目标是做成一个600GB的存储目录/data。第一步用fdisk给每块盘创建分区并修改分区类型fdisk /dev/sdb交互过程大致是输入n新建分区全部回车使用默认扇区输入t修改分区类型如果fdisk提示需要输入十六进制编号则输入8eLinux LVM最后输入w写盘退出。然后执行partprobe /dev/sdb让内核重新读取分区表避免重启才能生效。/dev/sdc做一样的操作。注意分区类型不改会造成一个非常经典的坑整个盘直接初始化为PV也能过但很多自动化工具和后续排错会因为它不是标准分区而识别异常。所以只要有条件规范的分区步骤不能省。4.2 创建PV、VG、LV接下来按顺序初始化物理卷、合并卷组、切割逻辑卷# 将分区初始化为物理卷 pvcreate /dev/sdb1 /dev/sdc1 # 创建名为 vg_data 的卷组 vgcreate vg_data /dev/sdb1 /dev/sdc1 # 从卷组中创建500G的逻辑卷 lv_data lvcreate -L 500G -n lv_data vg_data这里我故意只划500G而不是600G是因为生产环境最好留一部分空闲空间。将来业务突增、或者需要做LV快照时这100G的空闲空间就是缓冲。如果想让LV直接占满整个VG可以用lvcreate -l 100%FREE -n lv_data vg_data。创建完执行pvs、vgs、lvs三条命令验证应该能看到各自状态为正常。尤其是VG那一列要确认两个PV确实合并到了同一个VG里没有因为名字写错各建各的。4.3 格式化、挂载、开机自动挂载LV创建完成后还是一个裸设备需要格式化并挂载# 格式化为ext4日志模式默认即可 mkfs.ext4 /dev/vg_data/lv_data # 挂载到 /data mkdir -p /data mount /dev/vg_data/lv_data /data # 写入fstab实现开机自动挂载 echo UUID$(blkid -s UUID -o value /dev/vg_data/lv_data) /data ext4 defaults 0 0 /etc/fstab这里有一个必须强调的点千万不要图省事直接写/dev/vg_data/lv_data到fstab尤其在有多块盘、设备识别顺序可能变化的机器上。用UUID取的就是稳定标识命令里我直接用了shell命令带出UUID一步到位。写完fstab后建议执行mount -a测试一次或者直接重启验证。我发现很多线上故障就是因为fstab写错导致开机时无法挂载系统直接进入救援模式。4.4 初始化后快速验证挂载好之后回查四件事lsblk # 看树状结构 df -hT /data # 看文件系统大小与类型 vgs --units M # 看VG剩余空间确认备用空间 lvs /dev/vg_data/lv_data # 看LV当前大小这个验证习惯在每次扩容后都要做一遍能立刻暴露扩了但文件系统没变大这种问题。据统计我接手过的LVM相关故障里有将近一半是忘了做最后一步resize2fs。5. 扩容实战给根分区或数据卷在线加装硬盘5.1 整体扩容的两个阶段理解LVM扩容心里要有一张流程图物理盘 - PV - VG - LV - 文件系统。扩容时请求是反着来的但处理顺序是从前往后。第一阶段解决VG有没有空间。如果VG还有剩余空间跳到下一阶段如果VG不够空间就要把新盘或新的分区做成PV再用vgextend把它并进现有的VG。这就是很多人说的加硬盘扩容本质。第二阶段解决LV和文件系统够不够大。用lvextend先把LV撑大再调用对应文件系统的扩容命令resize2fsext4或xfs_growfsXFS把文件系统撑大。两个阶段顺序一定不能反先扩文件系统而LV没变文件系统会以为有空间结果写底层失败只扩LV不扩文件系统df里看到的大小不会变等于白忙活。5.2 数据卷扩容实例加一块新盘扩200G继续用上面的vg_data例子。业务涨了需要再扩200G新采购了一块200GB的盘/dev/sdd。# 分区并标记为LVM如果新盘想整盘直接做PV也可以省略fdisk fdisk /dev/sdd # n - t - 8e - w # 初始化PV并入卷组 pvcreate /dev/sdd1 vgextend vg_data /dev/sdd1 # LV扩容增加200G lvextend -L 200G /dev/vg_data/lv_data # 文件系统在线扩容ext4用resize2fs resize2fs /dev/vg_data/lv_data如果是XFS文件系统最后一步要改成# XFS的扩容命令必须传挂载点不能传设备路径 xfs_growfs /data这是ext4和XFS在扩容上最大的区别我提醒过很多同事看到LV确实是大了但df没变八成是漏了最后这步或者XFS用错了命令。5.3 Ubuntu/Kylin根分区扩容重点全流程根分区扩容是我被问得最多的一类场景尤其Ubuntu Server默认安装时使用LVM根分区的VG名往往是ubuntu-vgLV名是ubuntu-lv。Kylin系统同样基于类似的LVM布局操作流程可以完全参考。先确认根分区确实是LVMlsblk df -hT /如果/对应的设备是/dev/mapper/ubuntu--vg-ubuntu--lv这种那就确认好了。接下来把新增的硬盘变成PV并并进根卷组# 假设新盘是 /dev/sdb pvcreate /dev/sdb vgextend ubuntu-vg /dev/sdb注意这里我直接用整块盘做PV没有分区也是合法的。然后让LV吃掉所有剩余空间并自动扩展文件系统lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv resize2fs /dev/mapper/ubuntu--vg-ubuntu--lvlvextend -r是另一个选项它会在扩展LV后自动调用resize2fs一条命令搞定两件事。Kylin系统下如果你的VG名和LV名不是上面这两个就直接用vgs、lvs查看实际名称思路完全一致。5.4 扩容过程中我踩过的几个坑首先是vgchange -ay或lvchange没执行导致无法识别新扩容。这个问题通常发生在多路径存储环境扩容 PV 后先vgscan刷新卷组信息再vgchange -ay激活然后再动LV。其次是扩容完成后发现业务写入特别慢。这个通常是新加的盘和旧盘性能不同导致的比如原来的盘是SSD新加的是机械盘VG里混合了两种性能差异很大的PV。LVM线性映射会把数据跨PV分布性能会被慢盘拖累。解决问题要么找同型号同批次盘要么给关键LV单独建VG避免异构混用。第三是扩容前没有确认文件系统类型。有的系统根分区是XFS有的数据盘是btrfs如果一律执行resize2fs命令会直接报错。所以操作之前blkid看一下永远不亏。6. 缩容与调整LVM最需要谨慎的部分6.1 只有ext4能规整缩容XFS不行LVM很多宣传材料强调在线弹性调整容量这句话只说对了一半。LV层面的扩容确实可以在线完成但缩容绝对没有这么轻松。尤其XFS文件系统设计上只支持扩容、不支持缩容想缩只能备份后重建。这一点在做初始规划时就要想清楚日志、数据库归档目录如果用了XFS就得一次性规划到位后期只能加不能减。ext4支持缩容但有一个铁律必须离线操作。也就是说要先卸载文件系统再缩不能边挂载边缩。整个流程严格按下面的顺序来# 1. 卸载文件系统 umount /data # 2. 强制检查文件系统必须不报错才能继续 e2fsck -f /dev/vg_data/lv_data # 3. 先把文件系统缩到目标大小 resize2fs /dev/vg_data/lv_data 400G # 4. 再把LV缩到对应大小 lvreduce -L 400G /dev/vg_data/lv_data # 5. 重新挂载 mount /dev/vg_data/lv_data /data顺序为什么必须严格因为文件系统缩容后LV如果还比文件系统大这是安全的但如果反过来先把LV缩小了文件系统认为自己还有400G空间实际底层只有300G那写入到边界附近就会损坏数据。我见过不止一个人在这两步上搞反最后只能跑数据恢复工具损失非常大。6.2 缩容后的空间到底给了谁缩容出来的空间是回到LV所在VG里的变为VG的空闲空间。这意味着它不能直接用于另一个挂载点除非你把VG里的空闲空间再划成新的LV或者用它来扩充别的LV。在实际项目里我一般会把缩容出来的空间留着做快照或者作为临时容量池供其他卷紧急借调。尽量不让VG长期处于90%以上使用率给自己留一点余量。6.3 在线调整的边界在哪里经过实际操作总结我建议记住这三条边界在线扩LVext4和XFS都是安全的前提是VG够空间。在线缩LV一律不安全必须卸载并e2fsck。根分区因为无法卸载所以根分区几乎只能扩不能缩。如果确实要缩根分区得用live CD启动外部环境处理风险和复杂度飙升。7. 云环境下的LVM这套组合拳怎么打才不翻车7.1 云电脑/云服务器重装前先从LVM属组卸载下来热点里提到的云电脑使用了LVM并加入了数据盘重装前需要先从LVM卸载是一个特别典型、又特别容易忽略的问题。为什么会这样因为云主机重装系统时系统盘会被重新初始化而如果你把数据盘也挂到了同一个VG里重装后的新系统在启动时可能自动识别到这块数据盘上的LVM元数据出现VG同名冲突、引用关系混乱导致新系统无法正常挂载或者数据盘显示异常。正确做法是重装前把所有LV卸载和停用# 先确保所有逻辑卷已经卸载 umount /data umount /mnt/backup # 停用卷组让LVM状态变成不激活 vgchange -an vg_data执行完这两步数据盘上的LVM元数据虽然还在但VG处于未激活状态。重装系统后如果还需要继续用这些数据在新系统里执行vgscan和vgchange -ay就能把原VG重新激活挂载。如果重装后数据盘彻底不需要了那就一步到位清理干净vgremove vg_data pvremove /dev/vdb1这会把VG里的LV全部删除PV上的LVM标识也抹掉数据盘重新变回空裸盘。注意vgremove是不可逆的执行前务必确认数据已备份。7.2 系统盘和数据盘尽量不要放进同一个VG云环境里我的一条铁律是系统盘所在的VG不要混入云数据盘。因为系统盘在云主机生命周期里可能面临重置、更换镜象、重装等一系列操作一旦数据盘也挂进去了重装时处理不当会把整组逻辑卷折腾出一堆问题。数据盘建议单独建VG比如系统盘是ubuntu-vg数据盘就建一个vg_data互不干扰。这样无论是重装系统还是更换数据盘两边都互不影响。接下来把数据盘做成PV加入VG从VG中切LV挂载后续扩容就在数据盘VG内部操作。7.3 云环境下LVM的优点和缺点盘点为了说清楚什么时候该用、什么时候需要犹豫我列了个实际评估表项目优点缺点/风险我的处理建议在线扩容数据盘空间不足时加盘后不影响业务扩容前仍建议做一次快照或备份生产环境扩容前先打快照跨盘聚合多块小盘合成大卷突破单盘容量性能取决于最慢的那块盘尽量用同品牌同规格盘快照与克隆支持LV级别的快照备份恢复方便快照空间占VG快照太小会失效快照空间给LV实际用量的10%-20%重装系统风险数据盘独立VG时重装后易恢复混用一个VG时重装极易翻车系统盘与数据盘务必分开VG性能损耗现代内核下损耗可以忽略极端IO下映射层仍有微小开销OLTP交易库先压测再上线总的来说云主机场景下如果数据盘只有一块、容量固定不变不搞LVM也完全没问题但只要你有未来可能要扩容、可能要跨多块云盘的预期LVM依然是最高性价比的选择。8. 踩坑记录那些文档里不会明说的LVM细节8.1 pvcreate报not a partition or not recognized这个报错我见过太多次了。原因分两种要么你根本没分区直接对整块盘执行了pvcreate要么分区类型不是8e。前者可以用pvcreate /dev/sdb直接对整块盘做PV一样可以后者就需要用fdisk把分区ID改成8e再试。还有一个隐藏坑某些虚拟化环境里新加的盘需要先partprobe或者kpartx -a刷新内核分区表否则系统看不到新分区。8.2 lvextend成功了df却没有变化凡是LVM扩容之后执行df -h发现大小没变九成是漏了resize2fs/xfs_growfs。另一个容易漏的情况是你挂载的是另外一个LV路径。比如你在挂载点里写的是/dev/vg_data/lv_data但实际软件配置里用的是/dev/mapper/vg_data-lv_data这两个其实是一回事就怕你自己看着命令对着文件系统进行操作方向搞错。扩容后习惯性执行一遍lsblk和df -hT一起看能快速发现不一致。8.3 删除LV之前没确认挂载状态lvremove删起来很痛快但它不会管你文件系统是否还在挂载。如果LV正处于使用中删除后文件系统瞬间变成I/O错误。现在内核大多会拒绝删除正在使用的LV但保险起见还是先umount再lvremove。另外做好心理准备LV删除后数据不可恢复云环境没有快照的裸用LVM相当于在走钢丝。8.4 快照空间分配不当导致快照自动失效用LVM快照做备份时快照会随着源卷数据变化而增长。如果你给快照分配的容量太小比如源卷实际写了200G快照只给了5G快照很快就会被写满然后内核会把快照标记为无效。更麻烦的是很多人在做快照时没注意到快照都挂在同一个VG里一致在消耗VG剩余空间等后面扩容时才发现空间被快照占了。我的做法是数据量大的源卷快照分配10%-20%体积快照只用做短时间备份或验证不长期保留用完立刻删除快照恢复空间。8.5 给刚接触LVM的读者一点个人经验玩了这么多年磁盘管理我最真切的体会是好的存储架构不是靠出事以后想办法撑起来的而是靠事前把结构设计得稍微冗余一点扛过来的。具体来说就是三件事。第一系统盘和数据盘的VG一定分开第二每个VG至少保留5%到10%空余空间给扩容和快照第三每次结构变更前启动pvscan/vgscan或lvs留个现状记录变更结束后再对照一次确认没有意外变化。另外一个实用小技巧给每一块PV通过pvchange --uuid记录清晰的UUID映射关系并把对应的物理盘设备名记录在维护文档里。云环境里盘符漂移很常见提前记录能省下将来排查LVM元数据和物理盘对应关系时的大量时间。磁盘管理和LVM这两件事都不复杂但每个环节都要讲顺序、讲细节。把这套思路在测试环境完整跑几遍再上生产你会发现那些曾经让你手忙脚乱的扩容和维护其实都可以在一次又一次验证之后变得从容。