1. 传统分区与LVM的差距三个让我转向LVM的真实场景先说说我自己遇到的事。几年前我负责一台内部测试服务器跑着MySQL和几个Java应用系统盘当时只给分了40G。某天下午告警邮件突然弹出来根分区用了98%。我当时想的不是扩容而是先琢磨哪个目录能清——这是传统分区最大的问题分区大小在装系统时就被焊死了事后想改只能靠软链接、挂新盘、搬家这类笨办法。那天我最后是清了日志、删了旧安装包勉强腾出几个G但所有人都知道这只是续命不是治病。第二个场景更常见。业务数据增长很快当时买服务器时只配了一块600G的盘一年多以后就见底了。传统方案是再买一块盘格式化挂到某个目录然后把应用的数据目录指过去。听着顺理成章但实际一操作就难受了历史数据在旧盘新数据在新盘应用里全是绝对路径各种配置文件要改备份脚本要改监控要改。整个迁移过程小心翼翼生怕哪个程序还写着老路径。这个场景让我彻底意识到传统分区把一块盘的容量和一个目录的空间绑死了而业务需要的是目录空间可以跨多块盘自由分配。第三个场景是缩容和快照。有一次QA环境需要把某个分区从200G缩到120G腾出的空间给另一个压力测试用。传统分区想缩容几乎不可能只能重新分区、重新格式化、重新恢复数据。折腾一个周末。而LVM逻辑卷管理用一句话就能概括它的价值它把物理磁盘和文件系统看到的空间之间加了一层抽象于是你可以在系统运行状态下自由地扩容、缩容、跨盘合并、做快照。换句话说传统分区管理的是盘子本身LVM管理的是盘子里的空间池然后从池子里按需舀水。第三个场景对做服务器运维和私有云的人来说尤其重要。你装了一台机器初始规划不可能完全准确预测未来一年的数据增长本来就是伪命题。有了LVM磁盘管理就从分区规划变成了容量分配后者的灵活度完全不一样。这也是为什么主流Linux发行版在安装时默认推荐LVM布局云厂商的镜像也在大量使用。如果你还没接触过LVM或者用过但只停留在会看不会操作的水平这篇文章就是把我在各种环境里摸爬滚打的经验系统整理一遍。2. LVM四层结构拆解从物理盘到文件系统的完整链路理解LVM务必先理解它的层次。很多教程起手就讲命令不讲结构结果使用者一遇到问题就懵。我习惯把LVM拆成四层来说从上到下分别是文件系统层、逻辑卷层、卷组层、物理卷层。2.1 四层各自扮演什么角色物理卷PVPhysical Volume是LVM的地基。它可以是整块磁盘比如 /dev/sdb也可以是磁盘上的一个分区比如 /dev/sda2。但不管是哪种这块盘/分区必须先被标记为LVM成员也就是执行 pvcreate 之后它才叫物理卷。打个比方PV相当于你买回来的一袋袋水泥水泥本身没有房子属性但它是盖楼的原材料。卷组VGVolume Group是核心的空间池。一个VG可以汇集一块或多块PV的空间把这些空间的来源彻底打散。比如你有两块1T的盘都做成PV加入同一个VG这个VG就是2T的容量池。分配空间时LVM不会关心数据具体落在哪块物理盘上它只管理Pool里的空间块。套用上面的比方VG就是把几袋水泥倒进一个搅拌池里你不再关心哪一瓢水泥来自哪一袋。逻辑卷LVLogical Volume是从VG里划出来的虚拟分区。你对LV做的事与现实分区完全一样格式化、挂载、读写文件。区别在于LV的容量可以从VG里随时增加或减少不用动物理存储。好比从搅拌池里浇一块预制板出来预制板可以随时再加水泥变厚。文件系统Filesystem就是挂在LV之上的ext4、xfs那一层。需要特别注意的是LVM本身不管文件系统的事扩容LV后你还要单独告诉文件系统空间变大了否则内核识别了更大容量但文件系统还是按旧大小工作。这一步骤很多人漏掉我在后面会重点讲。2.2 PE这个参数为什么重要还有一个隐藏概念叫PEPhysical Extent物理扩展块它是VG分配空间的最小单位默认4MB。你在 lvcreate 时看到的 -l 参数单位也是PE比如-l 100表示分配100个PE即400MB。而-L 100M则是按容量分配。PE设多大直接影响两点一是大VG下如果PE太小元数据管理开销变大二是PE小则空间分配碎块少PE大则管理轻量但可能浪费空间。日常使用保持默认4MB完全够用。2.3 一图流看懂数据的流动路径整条链路用文字描述就是应用程序读写文件 → 通过文件系统ext4/xfs→ 落在逻辑卷LV→ 逻辑卷从卷组VG分配空间 → 卷组把空间映射到物理卷PV→ 最终读写物理磁盘。这个过程对上层完全透明。文件系统看到的只是一个设备文件比如 /dev/mapper/vgdata-lvdata它不知道自己后面还藏着多块物理盘。这与你用fdisk直接分区最大的区别直接分区是分区表写死LVM是逻辑映射动态调整。基础查看命令也要先熟起来这三条基本每天都会用pvs # 查看物理卷哪个设备是PV、属于哪个VG、大小多少 vgs # 查看卷组VG总容量、已分配、剩余空间 lvs # 查看逻辑卷LV名字、所属VG、大小、路径配合lsblk可以直观看到物理盘 → 分区 → PV → 挂载点的关系树这个后面会讲。先把四层结构“焊”在脑子里后面所有操作才不容易跑偏。3. 服务器上快速摸清磁盘家底必用命令与输出解读不管你是接手一台新服务器还是在排查磁盘告警第一步永远是搞清楚机器上到底有几块盘、怎么分区的、空间用到了什么程度。这步做扎实了后面动刀才敢下结论。3.1 lsblk磁盘与挂载关系一图看全我最推荐先跑 lsblk它对新手最友好输出是一棵清晰的树状结构。例如$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 500G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 499G 0 part └─vgroot-lvroot 253:0 0 120G 0 lvm / └─vgroot-lvdata 253:1 0 379G 0 lvm /data sdb 8:16 0 2T 0 disk └─vgdata-lvbackup 253:2 0 2T 0 lvm /backup注意 sda2 下面缩进的vgroot-lvroot和vgroot-lvdata说明这块分区是PV被分成了两个逻辑卷分别挂载到/和/data。TYPE列里的lvm直接告诉你这是LVM逻辑卷设备。sdb 整块盘也做成了LVM。看到这棵树的瞬间你就该明白sda2这块499G的分区并不是直接分配到一个目录而是进入了vgroot这个空间池然后池子被划分成120G根卷和379G数据卷。3.2 df文件系统视角的使用率lsblk看的是分配关系df看的是文件系统使用率。日常告警盯的就是df。$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/vgroot-lvroot ext4 118G 89G 23G 80% / /dev/mapper/vgroot-lvdata ext4 372G 200G 152G 57% /data-T显示文件系统类型这个信息在扩容时极其关键ext4和xfs的处理方式完全不同后面说。设备名里出现的/dev/mapper/xxx就是LVM逻辑卷的映射路径名字规律是vg名字-lv名字。如果看到的是/dev/sda1这类直接设备路径说明这个分区没走LVM是传统分区布局。3.3 判断一块盘是否属于LVM的两种方式一是看 lsblk 的TYPE列有没有lvm二是用blkid查看设备是否有LVM元数据$ blkid /dev/sdb /dev/sdb: UUIDxxx TYPELVM2_memberTYPE是LVM2_member就说明这是物理卷成员。如果是ext4或xfs则说明这个设备已经被格式化成文件系统直接使用了。这块知识在排查为什么这块盘挂不上时特别有用——很多人拿到一块旧盘直接mount报错就是因为压根没意识到它曾是LVM成员需要用pvscan和vgscan先看看它的归属。3.4 服务器上看磁盘的完整排查套路我给大家总结一条我日常用的命令链路照着跑一遍磁盘家底基本全部暴露lsblk # 看物理盘、分区、LVM、挂载点整体结构 df -hT # 看文件系统使用率确定告警级别 pvs vgs lvs # 看LVM三层各自的分配明细 fdisk -l # 确认每块物理盘的总容量和分区表类型 cat /proc/meminfo | head -1 # 顺带看一眼内存排查磁盘问题时经常要结合内存看这一套跑完你脑子里应该能回答出四个问题机器上有几块物理盘哪些盘/分区被LVM接管了每个VG的池子还剩多少空间当前哪个挂载点快满了。回答不了这四个问题之前不要动任何扩容或者迁移的念头。这些命令的输出全都可以复现没有任何门槛关键是形成看树→看表→看池子的习惯。4. 从零做LVM物理卷、卷组、逻辑卷的完整创建思路掌握了怎么看下一步就是动手。很多新手在创建LVM时容易犯一个错误——直接把整块盘做成PV结果之后想调整分区时反而没有操作空间。我下面给的流程是经过多次生产验证的标准步骤每一步都会解释为什么这样设计。4.1 场景假设与目标假设新买了一块2T的盘/dev/sdb目标是把这块盘变成LVM卷组vgdata的一部分并从中创建一个500G的逻辑卷lvapp挂载到/app。这个场景在真实运维里非常典型加新盘、扩充空间池、为新业务划分独立逻辑卷。生产服务器建议给每个业务/用途建独立LV而不是一股脑全塞到根卷里。独立LV的好处是各个业务的空间可以独立扩容缩容、独立做快照、独立卸载迁移互不干扰。4.2 标准创建命令序列第一步在/dev/sdb上创建物理卷pvcreate /dev/sdb如果你不确定 /dev/sdb 是否已有数据先跑pvs或blkid确认它 干净。pvcreate会写入LVM元数据破坏原有分区表和文件系统这是不可逆操作务必三思。第二步创建卷组。如果是要新建卷组vgcreate vgdata /dev/sdb如果是往已有的vg比如系统装好后就有的vgroot里加盘vgextend vgroot /dev/sdb这里有一个很关键的设计考量新盘加入已有VG和创建新VG两者决策路径完全不同。如果新盘容量是想独立使用、长期固定给某个应用建议新建VG如果想融入现有空间池、给现有逻辑卷扩容则用 vgextend。混合式也可以比如新盘一部分加入vgroot给根卷扩容剩下的划给新VG这个看现场需求。第三步创建逻辑卷lvcreate -L 500G -n lvapp vgdata这条命令表示在 vgdata 卷组里创建一个名为 lvapp 的500G逻辑卷。lvm默认的主设备路径是/dev/mapper/vgdata-lvapp同时也会生成/dev/vgdata/lvapp这种兼容路径。两条路径指向同一个东西你实际操作时用哪个都行但配置文件里尽量统一用/dev/mapper/xxx形式避免在某些发行版上调用的符号链接不一致导致挂载失败。如果想把VG里的剩余空间全部分配给逻辑卷用-l 100%FREElvcreate -l 100%FREE -n lvapp vgdata建议明确指定容量预留一部分空间在VG里后续扩容才有余地。除非这个LV就是奔着占满整个池子去的。第四步格式化并挂载mkfs.xfs /dev/mapper/vgdata-lvapp mount /dev/mapper/vgdata-lvapp /appxfs和ext4选择看场景。xfs在大型文件和高吞吐场景表现更好但不能缩容ext4灵活度更高可缩可扩但单文件系统上限和文件数量上限低于xfs。云服务器上常用xfs比如阿里云默认就是xfs很多企业内部自建环境沿用ext4。小白想省心小分区用ext4大数据量场景用xfs。第五步写入fstab实现开机自动挂载。用UUID而非设备名因为设备名比如 /dev/mapper/vgdata-lvapp在系统重启后有变化风险UUID是绝对稳定的标识。先查询UUIDblkid /dev/mapper/vgdata-lvapp将输出结果中的UUID复制编辑 /etc/fstabUUIDxxxx-xxxx /app xfs defaults 0 0这里有个经验之谈写完fstab后不要立即重启系统验证而是先执行mount -a这条命令会根据fstab重新挂载所有项目。如果语法或配置有问题mount -a 会当场报错你可以马上修正而不是等重启进不了系统才后悔。修改fstab导致开机无法挂载、卡在Emergency Mode的情况我见过太多全都是跳过这步导致。4.3 为什么不建议把整块盘直接格式化成文件系统这次创建流程里最值得讲清楚的问题是为什么非要绕一层LVM。答案是对服务器而言磁盘容量预测几乎不可能准确。你直接mkfs.xfs /dev/sdb然后挂载用满之后怎么办只能再买一块新盘数据搬过去路径重新指如果用LVM用满时只需再买盘、vgextend进VG、lvextend扩LV、文件系统在线扩容四步结束服务全程不停。多花的那一点创建时间换回的是未来扩容时省下的大把维护窗口。这就是我在生产环境里几乎不裸格式化的原因。5. Ubuntu根分区扩容全攻略从加盘到在线扩完的完整操作热词里有人搜“ubuntu根分区扩容全攻略:lvm”这几乎是云上Linux用户最常遇到的另一个需求。Ubuntu默认安装时通常使用LVM布局但很多用户在规划磁盘时不了解扩容的正确姿势总是在根分区将满时手忙脚乱。这里我直接给出从新物理盘接入到根分区真正变大的完整流程并解释每一步背后的逻辑。5.1 确认你用的文件系统类型先看清楚扩容对象是ext4还是xfs决定最后一步的差异df -T /Ubuntu默认一般是ext4云镜像定制另说但也有版本/厂商镜像用xfs。记下文件系统类型下面最后一步会用到。5.2 扩容操作全流程假设机器在当前虚拟机里增加了一块100G的新盘设备名为 /dev/sdb目标是把这100G全部并入根卷所在的VG然后全部扩给根LV。第一步操作系统识别新盘。虚拟机/云控制台添加磁盘后有的系统会自动识别有的需要触发重新扫描。先执行 lsblk 看是否出现 /dev/sdb。如果没出现执行echo 1 /sys/class/scsi_host/host0/scan若host0不行把 host0 换成 host1、host2 逐个试。云上Ubuntu一般添加后立即可见物理机则需要触发扫描。第二步创建PV并并入现有VG。先看当前VG名字vgs假设显示VG名为ubuntu-vg则执行pvcreate /dev/sdb vgextend ubuntu-vg /dev/sdbvgextend之后VG的剩余空间会增加100G。可以用 vgs 确认。第三步扩展逻辑卷。先看根LV的名字lvs假设根LV路径是/dev/ubuntu-vg/ubuntu-lv。将VG剩余空间全部扩给它lvextend -l 100%FREE /dev/ubuntu-vg/ubuntu-lv100%FREE表示把VG当前所有空闲空间都加给这个LV。注意这里不是逻辑卷扩容后文件系统就自动变大所以必须做第四步。第四步扩展文件系统。这是最容易踩坑的分水岭文件系统是 ext4resize2fs /dev/ubuntu-vg/ubuntu-lv文件系统是 xfsxfs_growfs /两个命令最重要的区别resize2fs 的参数是逻辑卷设备路径而 xfs_growfs 的参数是挂载点。xfs文件系统不支持缩容扩容只能朝一个方向走ext4可以缩容但缩容操作只能在卸载状态下进行风险高如果不是必要情况不建议缩。我的建议只要是生产环境且没有明确必须缩容的理由从一开始就把空间规划到宽松一点别指望缩容解决问题。第五步验证。df -h 看看 / 的容量应该已经变成原有容量加上100G考虑少量元数据损耗。5.3 实际扩容过程中的注意事项新盘加入VG时不能忽略PV创建这一步。很多人直接在 vgextend 里填 /dev/sdb系统会报错说不是物理卷。所以顺序必须是 pvcreate → vgextend这个顺序不能乱。根分区扩容时如果/boot也是独立分区且空间不足那是另一码事需要单独处理。LVM扩容解决的是根文件系统/的容量问题不解决/boot。如果/boot是独立分区且满了只能清理旧内核。清理旧内核的命令是 apt 系列中apt autoremove --purge的活rootfs扩容帮不上忙。在线扩容对生产环境是安全的因为lvextend和resize2fs/xfs_growfs都支持热操作不会中断正在进行的读写。但你仍然应该选择一个低峰窗口执行避免极端的IO竞争。还有一条铁律扩容前做快照或备份尤其是数据库、状态类应用。LVM虽然可以让扩容变得低风险但任何磁盘操作在完全不可控的环境里都有翻车的概率备份是底线。6. 云电脑与数据盘的特殊处理重装系统前为什么要先从LVM卸掉热搜词里有一条很有意思如果云电脑使用了lvm(逻辑卷管理)并加入了数据盘用户在重装前需要先从lvm卸。这其实是云服务器/云电脑用户非常容易踩的一个大坑而且网上这方面的完整解释反而少。6.1 为什么会踩这个坑先说背景。很多云电脑/云服务器创建时会默认系统盘使用LVM同时允许用户单独购买一块数据盘并把这块数据盘也做成了PV并加入了根卷所在的VG。这个过程通常是自动化的镜像脚本干的用户可能都没察觉到。结果重装系统时用户往往只在控制台勾选了重装操作系统没有从系统里把数据盘的PV解除。重装后的系统是一个全新的根VGVG的UUID变了PV的元数据也可能已经变化。这时你把当时那块数据盘再挂载回新系统新系统的LVM去扫描时可能同时遇到两个VG产生冲突——旧VG残留信息还在数据盘上新VG是新生成的。常见的混乱表现是新系统无法正常挂在数据盘因为设备已经有了LVM成员标识文件系统层面根本看不到数据挂载时报错说设备忙/结构需要清理/UUID不匹配更糟糕的情况下有人在重装时对系统盘做了重新分区初始化数据盘的PV元数据没有清除后续系统启动时LVM识别混乱连引导都可能受影响。6.2 正确的事前处理流程如果你确定机器上有一块数据盘曾经被纳入了LVM在重装前一定要按以下顺序在旧系统里操作第一步卸载数据盘上的文件系统。先查挂载情况df -h lsblk找到数据盘对应的挂载点比如 /data卸载它umount /data如果umount提示设备忙说明有进程还在使用。用 lsof 或 fuser 找出占用进程处理后再卸。第二步把数据盘的PV从VG中移除。先用 pvs 确认PV设备名比如 /dev/vdb。然后vgreduce vgname /dev/vdbvgname 是数据盘所在VG名pvs 输出里能看到。vgreduce 的含义是把这个PV从VG成员中拆掉之后VG不再依赖这块盘。第三步清除PV标记pvremove /dev/vdbpvremove 会清除 /dev/vdb 上的LVM元数据让这块盘重新变成一块干净的普通磁盘。做完这步数据盘上已经没有任何LVM痕迹了文件系统数据本身依然保留pvremove 不会动数据区只会擦掉LVM头部的元数据。第四步在云控制台/管理面卸载数据盘。此时数据盘已经完全脱离系统可以安全地从云电脑上解绑。6.3 万一已经带着LVM重装了怎么办如果没做上述处理就重装了也别慌还有挽救路径。新系统起来后执行 vgscan 和 pvscan 看看能否识别旧VGpvscan vgscan lvs如果 pvscan 能看到盘上有PV并且 vgscan 能恢复旧VG往往可以用 vgchange -ay 激活这个VG。但小心如果新系统和旧数据盘的VG同名LVM默认不会同时激活两个同名VG需要先重命名其中一个。重命名VG命令是vgrename oldvg newvg之后就可以 mount 相应的LV来拷数据。不过这个过程确实繁琐而且一旦旧VG的元数据被破坏数据恢复只能依赖备份工具所以尽量在重装窗口前按正规流程处理而不是事后补救。7. 麒麟Linux扩LVM国产系统下的步骤差异与典型坑点热词里出现了“kylin linux 扩lvm”这又是一个实际环境中经常遇到的需求。麒麟系统分银河麒麟基于CentOS/RHEL系和优麒麟基于Ubuntu系用户遇到的扩容问题通常集中在银河麒麟上因为很多政府、企业服务器部署的是这个版本。下面以银河麒麟为主讲差异和坑。7.1 银河麒麟与CentOS系LVM工具的一致性本质上银河麒麟的LVM功能与CentOS 7/8几乎完全一致。lvm2 工具链、内核设备映射机制、/dev/mapper 路径都没差异。所以 CentOS 的LVM扩容命令在银河麒麟上同样适用yum install -y lvm2 # 如果没装的话 pvcreate /dev/sdb vgextend centos-vg /dev/sdb # 注意VG名银河麒麟装系统时默认可能是 vg_root 或你自定义的名字 lvextend -l 100%FREE /dev/vg_root/lv_root resize2fs /dev/vg_root/lv_root # ext4 # xfs xfs_growfs /看起来跟Ubuntu差不多但实际坑点有两个。7.2 坑点1默认VG名不统一银河麒麟安装时的默认分区方案不同版本、不同架构的命名并不统一。有的版本VG名叫vg_kylin有的叫centos_vg有的直接是vg_root还有用vg0的。如果在实际服务器上按教程里的名字照抄百分之百会失败。正确的第一步永远是先用vgs或vgdisplay查看实际VG名然后再执行扩容。7.3 坑点2麒麟系统的系统盘分区布局银河麒麟默认安装时如果选择自动分区有时不会把所有空间全部交给LVM。例如系统盘500G自动分区可能只把前300G的物理卷并入VG剩下200G作为空闲未分配区或者留给了某个普通分区。这种情况下你会遇到两种奇怪现象一是 vgs 显示的VG容量远小于物理盘容量二是 lsblk 里物理盘下面既有LVM分区也有非LVM分区但你在fdisk里看到的剩余空间却没法直接加进VG。解决思路是如果你确认物理盘上还有未分配的空间可以用 parted 将其切成新分区或者直接把整块未分区设备加入VG。最安全的做法是使用 parted 调整分区表把空闲空间建为LVM分区类型分区类型代号8e然后 pvcreate 这个新分区vgextend 进VG。但如果你不确定盘上有没有重要数据请先备份。对生产环境上的麒麟机器我更推荐老老实实另加一块新盘来扩VG绕开分区表调整的风险。7.4 麒麟环境里的文件系统类型注意问题银河麒麟V10默认根文件系统通常是ext4但也有定制版使用xfs。执行扩容前先df -T /确认。如果根是xfs且执行resize2fs会直接报错必须改成xfs_growfs /。反过来说如果根是 ext4 而对xfs用xfs_growfs也会报错。这个错误提示对新手来说不太直观但排查路径很简单——先看文件系统类型再决定命令。最后一个提醒银河麒麟的软件源在国内镜像可用但在某些内网环境可能没有开放yum源。如果连 lvm2 工具都装不上pvcreate 这类命令会缺失先从本地ISO挂载配一个本地源再安装lvm2。我在内网环境遇到过很多次命令不存在的报错最后都是因为没配源导致的和LVM本身没有半点关系。8. LVM的边界哪些场景不适合以及我的运维经验清单聊完各种成功的扩容也得说说LVM的边界。任何工具都有不适合的场景盲目上LVM同样会吃苦头。8.1 三个不建议用LVM的场景第一个场景是数据库裸设备或者要求极致低延迟存储的物理机环境。LVM多了一层映射虽然现代内核里设备映射代价极小但延迟敏感的工作负载通常会绕过文件系统和逻辑卷直接把整个磁盘或者分区交给数据库管理。这个时候LVM引入的不确定性反而成了团队不愿承受的风险。第二个场景是单块盘、单分区、且容量几乎不会再变动的小机器。比如一台只有一块40G盘、只跑一个静态网站的轻量服务器没有扩容需求也没有快照需求直接 ext4 格式化分区即可多一层LVM反而增加管理复杂度。第三个场景是超大规模集群统一存储管理。几百台机器的磁盘如果都用LVM你又没有一个完善的配置管理工具如ansible脚本手动维护会变得非常痛苦。大部分集群场景下直接用云盘或者分布式存储比每台机器单独折腾LVM更合理。8.2 LVM快照的正确用法LVM的原生快照功能很多人没用过实属浪费。快照的原理是写时复制COW创建快照后原LV上被修改的数据块会被复制到快照区域快照始终保持某个时间点的状态。创建命令很简单lvcreate -L 20G -s -n snap_root /dev/vg_root/lv_root这会在 vg_root 里创建一个20G的快照卷 snap_root。生产环境大有好处的场景是升级软件包、改配置之前拍一个快照万一出问题可以秒级回滚。注意快照卷不能无限膨胀快照空间满了之后会自动失效所以快照大小要大于未来一段时间内原LV的写入量。不想用了直接lvremove移除快照卷不影响原LV。8.3 我在实际运维中的三点体会第一点监控VG剩余空间比监控某个文件系统使用率更有前瞻意义。你可以给每个文件系统定告警阈值但VG剩余空间才是扩容决策的直接参考。vgs 的剩余空间见底时即使当前所有LV都还没满也要未雨绸缪准备加盘了。第二点使用LVM后系统盘和数据盘到底要不要放到同一个VG里要慎重。如果只有一块盘没得选根和数据共用VG。如果有多块盘我倾向于系统盘独立VG数据盘独立VG。这样即使数据盘操作失误系统引导不会受影响相反系统盘容量告急也不至于牵连数据盘业务。之前不少人图省事把所有盘全并入一个VG结果某次在数据盘上做pvremove时差点把根卷空间卷进去冷汗都下来了。第三点所有LVM相关操作默认先开一个screen或tmux会话。扩容操作偶尔会出现网络断连终端卡死的情况如果操作在tmux里断线重连后操作现场还在不会出现lvextend执行到一半不知道成功没有的尴尬。我在云服务器上操作时都养成了这个习惯算是一个成本极低但受益无穷的小技巧。