前几天生产环境存储告警点开监控一看数据卷使用率已经94%这台CentOS 7.9上的LVM逻辑卷当初规划给了100T撑了两年半肉眼可见快满了。需求方的反馈很直接容量加到150T别停机别丢数据。整个扩容过程在线上完成没重启、没重新格式化、业务无感知。这篇就把完整思路和命令写出来从环境勘察、新盘识别、分区、PV/VG/LV扩展到文件系统在线调整一步不落。只要你的机器是CentOS 7 LVM这套组合这套流程可以直接套用。1. 扩容方案与LVM扩容基础1.1 为什么选LVM做在线扩容传统分区方式扩展一块盘要先在磁盘上重建分区再扩展文件系统操作繁琐不说很多场景下还必须卸载挂载点才能动。生产环境数据卷动不动就上百T卸载挂载点意味着业务中断这个代价没人愿意承担。LVMLogical Volume Manager把这层逻辑抽了出来物理盘或分区先抽象成PVPhysical Volume多个PV汇入VGVolume Group再从VG里切LVLogical Volume给文件系统用。加了新盘无非是让PV多一个成员、VG池子变大、LV原地扩大文件系统在线扩容底层数据不动。打个比方普通分区是固定大小的收纳盒LVM是一个可以不断加隔板的大抽屉抽屉扩容了里面每个收纳盒也能跟着调大。这次扩容的核心思路就三步新盘/新LUN加入VG、LV扩展到目标容量、文件系统跟随扩展。整个过程不涉及数据迁移也不用改挂载点风险相对可控。1.2 扩容前必须搞懂的单位换算讲命令之前必须先说清楚容量单位这个坑。存储厂商眼中的1TB是1000^4字节而Linux系统里看到的1TiB是1024^4字节两者差了大约2.4%。你在存储阵列管理面板里看到100TB映射到操作系统里df -h和lvs显示的大约是90.95TiB。所以从100T扩到150T这句话里100T到底是TB还是TiB直接影响你要扩容多少空间。这次实际环境中阵列侧新增了一个50TB的LUN系统里识别出来大约45.47TiB。如果按lvextend -L 50T执行LVM会理解为增加50TiB而PV实际可用只有45.47TiB直接报空间不足这个坑我后面还会再提。稳妥的做法是不猜容量直接用-l 100%FREE把VG里所有可用空间全给目标LV或者提前用pvs、vgs把精确的TiB值算出来再填数字。2. 扩容前环境勘察2.1 梳理当前存储拓扑生产环境动刀之前先把现状摸清楚。查看磁盘、LVM、文件系统三层信息我习惯用这几个命令lsblk -o NAME,SIZE,TYPE,MOUNTPOINT pvs vgs lvs df -hT当时输出的关键信息大概长这样$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT NAME SIZE TYPE MOUNTPOINT sda 200G disk ├─sda1 500M part /boot ├─sda2 2G part [SWAP] └─sda3 197.5G part └─vg_data-lv_data 197.5G lvm / sdb 100T disk └─sdb1 100T part └─vg_data-lv_data 100T lvm /data数据卷挂载在/data逻辑卷路径是/dev/mapper/vg_data-lv_dataVG名称vg_data。df -hT输出确认文件系统类型为xfs这是CentOS 7的默认选择也符合大容量场景的惯例。如果环境里使用了multipath多路径还要额外执行multipath -ll确认LUN的映射情况/dev/sdX这种名字在重启后可能变化后面配置和管理都应该以/dev/mapper/路径为准。2.2 备份与业务确认在线扩容虽然成熟但谁也不敢保证底层阵列不会突然抖动或者链路过载。操作前一定要把退路想好存储侧做一次快照、备份作业确认最近一次完整备份成功、数据库侧如果是核心业务最好有主从或日志归档兜底。别嫌麻烦这次省掉备份下次出问题就真成事故复盘了。选择操作时间也有讲究。避开业务高峰尤其是批处理、结算、报表这类重IO时段。扩容过程中LVM会写入元数据文件系统扩展也会触发一些元数据操作虽然正常来说非常快但如果赶上高峰期IO压力大响应时间会被拉长。我这次选在凌晨低峰期操作还提前通知了相关业务同学留了半小时观察窗口。3. 新物理盘识别与分区处理3.1 让系统识别新磁盘阵列侧把50TB新LUN映射过来后操作系统不会自动发现它。如果在lsblk里看不到新盘先看内核有没有感知到dmesg | grep -i sd如果没有任何新增磁盘信息手动触发一次SCSI扫描for host in /sys/class/scsi_host/host*; do echo - - - $host/scan; done这条命令会扫描所有SCSI主机总线让系统发现新增的LUN。扫描完成后再次执行lsblk应该能看到新盘比如/dev/sdc。物理机上的HBA卡和虚拟机场景略有不同VMware环境里如果给虚机加了盘客户机不一定即时感知在虚拟机的SCSI控制器上执行一次重新扫描或者上面的SCSI扫描命令即可。总之尽量在线扫描没必要为一台存量服务器重启浪费窗口。3.2 使用parted创建GPT分区新盘是否分区业界一直有争论。我的习惯是分区原因有三第一分区上能打LVM标志后续管理识别更直观第二某些存储多路径软件对整块裸盘建PV会有告警第三遇到更换盘符、迁移设备时分区表能减少误操作风险。MBR分区表最大只能管理2T磁盘100T规模必须用GPT。分区工具用parted不支持GPT的旧版fdisk直接放弃。命令如下parted -s /dev/sdc mklabel gpt parted -s /dev/sdc mkpart primary 0% 100% parted -s /dev/sdc set 1 lvm on partprobe /dev/sdc分区完成后核对一下对齐情况命令输出1 aligned表示扇区对齐正常parted /dev/sdc align-check optimal 1大容量LUN底层很可能是RAID组或SSD存储池分区对齐直接影响IO性能。如果用了旧的起始扇区如63扇区会产生严重的跨扇区读写性能可能下降20%以上。所以在生产环境里凡是新盘分区我都会把align-check这一步做掉不等性能报告出来再后悔。4. PV创建与VG扩展4.1 确认设备路径避免张冠李戴创建PV之前最重要的不是命令本身而是确定你要操作的是新盘而不是旧盘。/dev/sdc这个设备名在重启后可能变成/dev/sdd甚至在你扩容过程中因为底层扫描顺序变了而发生跳变。多路径环境下尤其明显。当时我先用multipath -ll确认了LUN的WWID再通过/dev/disk/by-id/找到对应设备ls -l /dev/disk/by-id/wwn-*找到新LUN对应的wwn链接后再用它后面的实际路径操作。这一步看似多余实际上能避免一个致命错误——如果你在pvcreate时填错了设备路径向一块已有数据的盘上写入PV标签数据直接报废神仙难救。4.2 pvcreate与vgextend实战确认无误后创建PV并加入VGpvcreate /dev/sdc1 vgextend vg_data /dev/sdc1pvcreate会在分区头部写入LVM元数据。执行后可以用pvs查看新PV状态这时VG列应该是空的因为还没加入任何卷组。加入VG后再次查看$ pvs PV VG Fmt Attr PSize PFree /dev/sda3 vg_data lvm2 a-- 99.08t 0 /dev/sdc1 vg_data lvm2 a-- 45.47t 45.47t看到/dev/sdc1的VG列变成vg_data并且VG总容量从99.08t增长到144.55t说明扩容的底层链路已经打通。vgextend操作的只是元数据不会触碰现有数据整个过程非常快对业务也没有影响但依然建议第一次操作的人执行完这一步后停下来对照预期容量确认一遍再继续。5. LV扩容与文件系统调整5.1 lvextend单位选择与空间计算VG扩展完成接下来把空间分配给LV。目标LV是/dev/mapper/vg_data-lv_data挂载在/data对应文件系统是xfs。查看VG剩余空间vgs输出显示vg_data的VFree大约是45.47t。如果直接把整个VG剩余空间全部给这个LV最省事的命令是lvextend -l 100%FREE /dev/mapper/vg_data-lv_data这个写法不需要关心容量单位LVM会自动计算可用VG空间并全部扩展到指定LV上。如果需求明确说要再扩大50T那就要注意单位lvextend -L 50T中的T是TiB会尝试增加50TiB而上面提到新PV只有45.47TiB必然报Insufficient free space。正确做法是使用十进制的TB后缀或者直接按系统识别的TiB数值填写lvextend -L 45.47T /dev/mapper/vg_data-lv_data不过填小数存在精度问题最稳妥还是-l 100%FREE。执行完成后lvs里LV的大小变为约141.54t但这只是LVM层面的容量变化文件系统还没感知到。5.2 xfs_growfs与resize2fs的区别CentOS 7默认文件系统是xfsxfs工具链有一个和ext4完全不同的特性只支持扩容不支持缩容。这意味着你给xfs所在的LV扩容之后如果想退回去基本不可能。所有空间规划必须一次到位这也是我在操作前反复确认目标容量的原因。xfs扩容命令是对挂载点操作的xfs_growfs /data命令会读取挂载点对应的设备并将其上的xfs文件系统扩展到底层LV的完整大小。执行过程极快几十T的文件系统扩展也就几秒钟。输出里可以看到data blocks changed from ... to ...这行信息就是确认扩容生效的依据。如果你的环境用的是ext4对应的调整命令是resize2fs /dev/mapper/vg_data-lv_dataext4的resize可以指定大小也可以不带参数自动扩展到LV最大空间。判断文件系统类型别靠记忆执行下面命令看输出df -T /data6. 扩容验证与效果6.1 容量核对文件系统扩容完成用df验证最终结果$ df -hT /data Filesystem Type Size Used Use% Mounted on /dev/mapper/vg_data-lv_data xfs 142T 90T 64% /data从扩容前的约97T到现在的142T容量提升明显业务数据完好。这里解释一下为什么不是整数150因为厂商的150TB换算成TiB大约就是136~142TiB具体数值还要看阵列的实际可用容量、RAID损耗和文件系统预留空间这类差异属于正常现象。再确认一遍LVM元数据lvs vgsLV大小和VG总容量都在预期范围内。如果环境里有监控系统记得把存储阈值重新设置一下按新容量95%的告警线重新计算不然监控面板会一直显示旧的容量基线。6.2 性能与稳定性观察扩容后我没有马上收工而是在/data下做了几轮写测试确认新加入的PV能正常读写。用iostat观察新盘所在设备的IO情况iostat -x 1 5如果底层阵列上新LUN来自不同的RAID组性能特征可能和旧LUN不一样。比如旧LUN在RAID10上新LUN在RAID6上混合进同一个LV后热数据可能在两套RAID间流动IO延迟会出现差异。短期看影响不大长期如果对性能敏感可以考虑按数据目录拆分不同LV而不是把所有盘混在一个池子里。7. 常见问题与避坑指南7.1 四个高概率报错场景把这次扩容以及过往碰到的典型报错整理成一张速查表遇到对应报错可以直接参考报错现象原因分析解决办法Device /dev/sdc not found (or ignored by filtering)内核未识别新盘或LVM过滤规则将其排除重新扫描SCSI总线确认使用的是分区设备而非整盘排查/etc/lvm/lvm.conf的filter配置Insufficient free space for 50T容量单位理解错误T是TiB不是厂商TB改用-l 100%FREE或按pvs显示的TiB精确值填写xfs_growfs: /data is not a mounted XFS filesystem文件系统不是xfs命令用错先df -T /data确认文件系统类型ext4环境改用resize2fsPartition 1 does not start on physical sector boundary分区起始位置未对齐常见于手工输入起始扇区删除分区重建parted直接使用0%起始即可生产环境遇到报错第一反应不是反复重试命令而是把dmesg、/var/log/messages、LVM命令的详细输出抓出来确认状态后再说。盲目重试可能让元数据处于不确定状态。7.2 运维习惯建议操作全程用tmux或screen挂住会话防止SSH断连导致命令执行中断这是生产操作的基本功。扩容前把所有关键命令的输出存一份快照文件比如pvs、vgs、lvs、df -h方便事后对比和回溯。扩容完成后把LVM拓扑和容量信息同步到CMDB和运维文档这一点看似不起眼却是很多团队最薄弱的环节。半年后系统出问题接手的人如果能直接查到这个LV跨了几块PV、底层是哪些LUN、文件系统是xfs只可扩不可缩排查效率会高很多。我个人每次做完这类扩容还会顺手在LVM设备名上打一层语义清晰的标签比如通过vgrename按业务命名卷组避免后续一堆vg_data、vg_data_bak分不清。最后再分享一个经验xfs的文件系统只能扩不能缩所以在LV规划阶段就要想清楚长期容量趋势。是扩到150T还是留到180T如果只扩50T半年后又满了还得再走一遍流程性价比不高。我这次直接按100%FREE全部划给数据卷给后续业务增长留足空间。存储扩容不怕多就怕不够用的时候再动一次生产。
前几天生产环境存储告警点开监控一看数据卷使用率已经94%这台CentOS 7.9上的LVM逻辑卷当初规划给了100T撑了两年半肉眼可见快满了。需求方的反馈很直接容量加到150T别停机别丢数据。整个扩容过程在线上完成没重启、没重新格式化、业务无感知。这篇就把完整思路和命令写出来从环境勘察、新盘识别、分区、PV/VG/LV扩展到文件系统在线调整一步不落。只要你的机器是CentOS 7 LVM这套组合这套流程可以直接套用。1. 扩容方案与LVM扩容基础1.1 为什么选LVM做在线扩容传统分区方式扩展一块盘要先在磁盘上重建分区再扩展文件系统操作繁琐不说很多场景下还必须卸载挂载点才能动。生产环境数据卷动不动就上百T卸载挂载点意味着业务中断这个代价没人愿意承担。LVMLogical Volume Manager把这层逻辑抽了出来物理盘或分区先抽象成PVPhysical Volume多个PV汇入VGVolume Group再从VG里切LVLogical Volume给文件系统用。加了新盘无非是让PV多一个成员、VG池子变大、LV原地扩大文件系统在线扩容底层数据不动。打个比方普通分区是固定大小的收纳盒LVM是一个可以不断加隔板的大抽屉抽屉扩容了里面每个收纳盒也能跟着调大。这次扩容的核心思路就三步新盘/新LUN加入VG、LV扩展到目标容量、文件系统跟随扩展。整个过程不涉及数据迁移也不用改挂载点风险相对可控。1.2 扩容前必须搞懂的单位换算讲命令之前必须先说清楚容量单位这个坑。存储厂商眼中的1TB是1000^4字节而Linux系统里看到的1TiB是1024^4字节两者差了大约2.4%。你在存储阵列管理面板里看到100TB映射到操作系统里df -h和lvs显示的大约是90.95TiB。所以从100T扩到150T这句话里100T到底是TB还是TiB直接影响你要扩容多少空间。这次实际环境中阵列侧新增了一个50TB的LUN系统里识别出来大约45.47TiB。如果按lvextend -L 50T执行LVM会理解为增加50TiB而PV实际可用只有45.47TiB直接报空间不足这个坑我后面还会再提。稳妥的做法是不猜容量直接用-l 100%FREE把VG里所有可用空间全给目标LV或者提前用pvs、vgs把精确的TiB值算出来再填数字。2. 扩容前环境勘察2.1 梳理当前存储拓扑生产环境动刀之前先把现状摸清楚。查看磁盘、LVM、文件系统三层信息我习惯用这几个命令lsblk -o NAME,SIZE,TYPE,MOUNTPOINT pvs vgs lvs df -hT当时输出的关键信息大概长这样$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT NAME SIZE TYPE MOUNTPOINT sda 200G disk ├─sda1 500M part /boot ├─sda2 2G part [SWAP] └─sda3 197.5G part └─vg_data-lv_data 197.5G lvm / sdb 100T disk └─sdb1 100T part └─vg_data-lv_data 100T lvm /data数据卷挂载在/data逻辑卷路径是/dev/mapper/vg_data-lv_dataVG名称vg_data。df -hT输出确认文件系统类型为xfs这是CentOS 7的默认选择也符合大容量场景的惯例。如果环境里使用了multipath多路径还要额外执行multipath -ll确认LUN的映射情况/dev/sdX这种名字在重启后可能变化后面配置和管理都应该以/dev/mapper/路径为准。2.2 备份与业务确认在线扩容虽然成熟但谁也不敢保证底层阵列不会突然抖动或者链路过载。操作前一定要把退路想好存储侧做一次快照、备份作业确认最近一次完整备份成功、数据库侧如果是核心业务最好有主从或日志归档兜底。别嫌麻烦这次省掉备份下次出问题就真成事故复盘了。选择操作时间也有讲究。避开业务高峰尤其是批处理、结算、报表这类重IO时段。扩容过程中LVM会写入元数据文件系统扩展也会触发一些元数据操作虽然正常来说非常快但如果赶上高峰期IO压力大响应时间会被拉长。我这次选在凌晨低峰期操作还提前通知了相关业务同学留了半小时观察窗口。3. 新物理盘识别与分区处理3.1 让系统识别新磁盘阵列侧把50TB新LUN映射过来后操作系统不会自动发现它。如果在lsblk里看不到新盘先看内核有没有感知到dmesg | grep -i sd如果没有任何新增磁盘信息手动触发一次SCSI扫描for host in /sys/class/scsi_host/host*; do echo - - - $host/scan; done这条命令会扫描所有SCSI主机总线让系统发现新增的LUN。扫描完成后再次执行lsblk应该能看到新盘比如/dev/sdc。物理机上的HBA卡和虚拟机场景略有不同VMware环境里如果给虚机加了盘客户机不一定即时感知在虚拟机的SCSI控制器上执行一次重新扫描或者上面的SCSI扫描命令即可。总之尽量在线扫描没必要为一台存量服务器重启浪费窗口。3.2 使用parted创建GPT分区新盘是否分区业界一直有争论。我的习惯是分区原因有三第一分区上能打LVM标志后续管理识别更直观第二某些存储多路径软件对整块裸盘建PV会有告警第三遇到更换盘符、迁移设备时分区表能减少误操作风险。MBR分区表最大只能管理2T磁盘100T规模必须用GPT。分区工具用parted不支持GPT的旧版fdisk直接放弃。命令如下parted -s /dev/sdc mklabel gpt parted -s /dev/sdc mkpart primary 0% 100% parted -s /dev/sdc set 1 lvm on partprobe /dev/sdc分区完成后核对一下对齐情况命令输出1 aligned表示扇区对齐正常parted /dev/sdc align-check optimal 1大容量LUN底层很可能是RAID组或SSD存储池分区对齐直接影响IO性能。如果用了旧的起始扇区如63扇区会产生严重的跨扇区读写性能可能下降20%以上。所以在生产环境里凡是新盘分区我都会把align-check这一步做掉不等性能报告出来再后悔。4. PV创建与VG扩展4.1 确认设备路径避免张冠李戴创建PV之前最重要的不是命令本身而是确定你要操作的是新盘而不是旧盘。/dev/sdc这个设备名在重启后可能变成/dev/sdd甚至在你扩容过程中因为底层扫描顺序变了而发生跳变。多路径环境下尤其明显。当时我先用multipath -ll确认了LUN的WWID再通过/dev/disk/by-id/找到对应设备ls -l /dev/disk/by-id/wwn-*找到新LUN对应的wwn链接后再用它后面的实际路径操作。这一步看似多余实际上能避免一个致命错误——如果你在pvcreate时填错了设备路径向一块已有数据的盘上写入PV标签数据直接报废神仙难救。4.2 pvcreate与vgextend实战确认无误后创建PV并加入VGpvcreate /dev/sdc1 vgextend vg_data /dev/sdc1pvcreate会在分区头部写入LVM元数据。执行后可以用pvs查看新PV状态这时VG列应该是空的因为还没加入任何卷组。加入VG后再次查看$ pvs PV VG Fmt Attr PSize PFree /dev/sda3 vg_data lvm2 a-- 99.08t 0 /dev/sdc1 vg_data lvm2 a-- 45.47t 45.47t看到/dev/sdc1的VG列变成vg_data并且VG总容量从99.08t增长到144.55t说明扩容的底层链路已经打通。vgextend操作的只是元数据不会触碰现有数据整个过程非常快对业务也没有影响但依然建议第一次操作的人执行完这一步后停下来对照预期容量确认一遍再继续。5. LV扩容与文件系统调整5.1 lvextend单位选择与空间计算VG扩展完成接下来把空间分配给LV。目标LV是/dev/mapper/vg_data-lv_data挂载在/data对应文件系统是xfs。查看VG剩余空间vgs输出显示vg_data的VFree大约是45.47t。如果直接把整个VG剩余空间全部给这个LV最省事的命令是lvextend -l 100%FREE /dev/mapper/vg_data-lv_data这个写法不需要关心容量单位LVM会自动计算可用VG空间并全部扩展到指定LV上。如果需求明确说要再扩大50T那就要注意单位lvextend -L 50T中的T是TiB会尝试增加50TiB而上面提到新PV只有45.47TiB必然报Insufficient free space。正确做法是使用十进制的TB后缀或者直接按系统识别的TiB数值填写lvextend -L 45.47T /dev/mapper/vg_data-lv_data不过填小数存在精度问题最稳妥还是-l 100%FREE。执行完成后lvs里LV的大小变为约141.54t但这只是LVM层面的容量变化文件系统还没感知到。5.2 xfs_growfs与resize2fs的区别CentOS 7默认文件系统是xfsxfs工具链有一个和ext4完全不同的特性只支持扩容不支持缩容。这意味着你给xfs所在的LV扩容之后如果想退回去基本不可能。所有空间规划必须一次到位这也是我在操作前反复确认目标容量的原因。xfs扩容命令是对挂载点操作的xfs_growfs /data命令会读取挂载点对应的设备并将其上的xfs文件系统扩展到底层LV的完整大小。执行过程极快几十T的文件系统扩展也就几秒钟。输出里可以看到data blocks changed from ... to ...这行信息就是确认扩容生效的依据。如果你的环境用的是ext4对应的调整命令是resize2fs /dev/mapper/vg_data-lv_dataext4的resize可以指定大小也可以不带参数自动扩展到LV最大空间。判断文件系统类型别靠记忆执行下面命令看输出df -T /data6. 扩容验证与效果6.1 容量核对文件系统扩容完成用df验证最终结果$ df -hT /data Filesystem Type Size Used Use% Mounted on /dev/mapper/vg_data-lv_data xfs 142T 90T 64% /data从扩容前的约97T到现在的142T容量提升明显业务数据完好。这里解释一下为什么不是整数150因为厂商的150TB换算成TiB大约就是136~142TiB具体数值还要看阵列的实际可用容量、RAID损耗和文件系统预留空间这类差异属于正常现象。再确认一遍LVM元数据lvs vgsLV大小和VG总容量都在预期范围内。如果环境里有监控系统记得把存储阈值重新设置一下按新容量95%的告警线重新计算不然监控面板会一直显示旧的容量基线。6.2 性能与稳定性观察扩容后我没有马上收工而是在/data下做了几轮写测试确认新加入的PV能正常读写。用iostat观察新盘所在设备的IO情况iostat -x 1 5如果底层阵列上新LUN来自不同的RAID组性能特征可能和旧LUN不一样。比如旧LUN在RAID10上新LUN在RAID6上混合进同一个LV后热数据可能在两套RAID间流动IO延迟会出现差异。短期看影响不大长期如果对性能敏感可以考虑按数据目录拆分不同LV而不是把所有盘混在一个池子里。7. 常见问题与避坑指南7.1 四个高概率报错场景把这次扩容以及过往碰到的典型报错整理成一张速查表遇到对应报错可以直接参考报错现象原因分析解决办法Device /dev/sdc not found (or ignored by filtering)内核未识别新盘或LVM过滤规则将其排除重新扫描SCSI总线确认使用的是分区设备而非整盘排查/etc/lvm/lvm.conf的filter配置Insufficient free space for 50T容量单位理解错误T是TiB不是厂商TB改用-l 100%FREE或按pvs显示的TiB精确值填写xfs_growfs: /data is not a mounted XFS filesystem文件系统不是xfs命令用错先df -T /data确认文件系统类型ext4环境改用resize2fsPartition 1 does not start on physical sector boundary分区起始位置未对齐常见于手工输入起始扇区删除分区重建parted直接使用0%起始即可生产环境遇到报错第一反应不是反复重试命令而是把dmesg、/var/log/messages、LVM命令的详细输出抓出来确认状态后再说。盲目重试可能让元数据处于不确定状态。7.2 运维习惯建议操作全程用tmux或screen挂住会话防止SSH断连导致命令执行中断这是生产操作的基本功。扩容前把所有关键命令的输出存一份快照文件比如pvs、vgs、lvs、df -h方便事后对比和回溯。扩容完成后把LVM拓扑和容量信息同步到CMDB和运维文档这一点看似不起眼却是很多团队最薄弱的环节。半年后系统出问题接手的人如果能直接查到这个LV跨了几块PV、底层是哪些LUN、文件系统是xfs只可扩不可缩排查效率会高很多。我个人每次做完这类扩容还会顺手在LVM设备名上打一层语义清晰的标签比如通过vgrename按业务命名卷组避免后续一堆vg_data、vg_data_bak分不清。最后再分享一个经验xfs的文件系统只能扩不能缩所以在LV规划阶段就要想清楚长期容量趋势。是扩到150T还是留到180T如果只扩50T半年后又满了还得再走一遍流程性价比不高。我这次直接按100%FREE全部划给数据卷给后续业务增长留足空间。存储扩容不怕多就怕不够用的时候再动一次生产。
