1. 一套缩写差点让我在扩容当晚翻车1.1 初次面对这五个缩写时的真实场景刚转做系统运维那阵我接手了一台运行着核心业务的 AIX 小型机。业务方晚上七点提了扩容工单数据目录剩余空间不到 5%希望当晚完成翻倍。我那时候对 Linux LVM 已经有了点使用基础脑子里默认的计划格外清晰——加一块盘做成 PV塞进 VG再把 LV 撑大最后 resize 文件系统。结果登录机子之后命令完全不对路。pvcreate不存在lsvg倒是有可我看不懂输出里那些 LP、PP、VGSTATE、VARYON 到底在说什么。最尴尬的是我连该扩的是LP还是PP都没想明白下mklv命令时差点把卷组可用分区算错。最后靠同事远程指导按先加物理卷、再扩展卷组、再改逻辑卷大小、再扩文件系统的顺序一步步补完才没造成业务中断。那次经历给我留下非常深的印象VG、PV、PP、LV、LP 这五个缩写不是同一套体系里的五胞胎而是层层递进的五层存储架构。少理解任何一层关键时刻都会出错。1.2 这五个缩写解决的是同一个核心问题把这些缩写背后的问题翻译成大白话怎么把一个物理硬盘的能力变成业务系统随时可以调整大小的逻辑盘。物理硬盘买回来就那么大分区一改就要动业务实在太僵化。LVM 的思路是在物理硬盘和文件系统之间增加一个抽象的中间层让空间可以跨盘聚合、在线伸缩、动态迁移。PV、PP、VG、LV、LP 就是这个中间层在不同尺度上的零件。PVPhysical Volume物理卷物理硬盘在被 LVM 收纳后的身份。PPPhysical Partition物理分区AIX 里物理卷上空间分配的最小单位。VGVolume Group卷组多个物理卷聚合成的资源池。LVLogical Volume逻辑卷从资源池里切出来、真正给业务使用的逻辑盘。LPLogical Partition逻辑分区逻辑卷内部的基本组成单位负责把逻辑空间映射回物理空间。需要说明的是这套带 PP 和 LP 的叫法是 AIX 体系里的标准说法。Linux 的 LVM 简化了一些没有 LP 这一层分配单位叫 PE物理扩展和 LE逻辑扩展映射基本是一比一。两种体系的核心思想一样但细节差别会直接影响命令和排查思路所以后面我专门用一整章做对比。1.3 什么样的人需要把这套体系吃透第一类是最直接受益的AIX 小型机管理员日常做卷组、逻辑卷、文件系统扩容、镜像和故障恢复全部绕不开这五个词。第二类是从 Linux 转过来或者两种平台都要维护的运维工程师理解了 AIX 的 PP/LP再回看 Linux 的 LVM 会非常轻松。第三类是云环境里的后端开发和存储规划人员虽然平时面对的是块存储、云盘和卷但真正要理解为什么一个卷可以先在线扩容再重新挂载底层依然是这套物理卷、卷组、逻辑卷的模型。这篇文章不会只讲概念。每一章都会给出命令走查、真实场景里的排查思路以及我在维护环境里总结的检查清单。看完可以直接拿命令套路去自己的实验环境里试一遍再对照手册理解参数效率会高很多。2. 从物理盘到逻辑卷把 VG、PV、PP、LV、LP 按层级摆顺2.1 PV物理卷是存储世界的地基在 AIX 里PV 通常对应一个hdisk设备它可能是一块物理磁盘、磁盘阵列中划分的 LUN或者虚拟化平台映射出来的 vdisk。一个 PV 被纳入 LVM 管理前需要先初始化相当于给这块盘打上 LVM 的识别标签记录盘上有哪些 PP、哪些 PP 已分配、哪些还没分配这些信息保存在盘上的固定位置。Linux 里这一步是pvcreateAIX 里通常在创建卷组时由mkvg顺手完成不需要单独执行。PV 的一个关键特性是它被划入某个 VG 之后就不再以一整块盘为单位去参与分配而是以 PP 为单位。所以哪怕两个 PV 大小不一样、来自不同厂商只要进同一个 VG它们的地盘就能被统一调度。这一点和 Linux LVM 非常接近底层细节被隐藏上层只看到卷组里有多少可用空间。我见过的常见误区是有人以为 PV 等于盘上的某个分区比如/dev/sda1。实际上在传统 LVM 里PV 可以建立在整块盘上也可以建立在独立分区上在 AIX 里更常见的是直接用整个 hdisk。分区和 PV 是两回事分区表是操作系统的磁盘分区概念PV 是 LVM 资源池的入池单位。2.2 PPAIX 分配空间的最小刻度PP 是 AIX LVM 里最有特色的概念。它把 PV 这块物理卷进一步切成固定大小的格子卷组内所有 PV 的 PP 大小必须一致。PP 大小在创建卷组时确定比如mkvg -s 8表示每个 PP 是 8MB。之后如果要在卷组里创建逻辑卷空间需求会被换算成需要多少个 LPLP 再指向具体哪个 PP。为什么要有这个格子因为在没有 PP 抽象之前一块盘上的空间要么被整个分区占用要么用非常复杂的起止扇区记录来管理扩容、缩容、镜像都非常痛苦。有了固定大小的 PPLVM 做三件事都很方便一是分配空间时只要数格子二是做条带化时可以在不同 PV 上取固定格子交替排布三是做镜像时能轻松维护同一份逻辑数据对应两个物理格子的映射关系。PP 大小的选择是个权衡太小映射表细粒度灵活但管理开销和元数据占用更高太大映射表粗管理省事但逻辑卷扩容时会浪费空间而且一些场景下差一点就够用的小卷会特别尴尬。我维护的 AIX 环境里业务数据卷组常用 4MB 或 8MB 的 PP如果是大数据平台一类的大单体文件系统会考虑 64MB 或更高。这个没有绝对标准取决于你的卷数量级和增长节奏。2.3 VG把一堆 PV 收纳成一个资源池卷组是整个 LVM 的调度中枢。一个 VG 可以包含一个或多个 PVVG 建立后所有 PV 上的 PP 被统一编号管理形成一个跨磁盘的大仓库。业务系统看到的逻辑卷全部从 VG 里切至于这个逻辑卷的底层落在哪块盘上由 LVM 根据映射策略决定业务和文件系统都不需要关心。查 VG 状态AIX 里用lsvg单个 VG 的详细情况用lsvg datavg查看某个 VG 里有哪几个 PV 用lsvg -p datavg。输出里常见VG STATE为active或inactive这对应 AIX 的卷组已激活/未激活概念。卷组必须先 varyonvg 激活里面的逻辑卷才能被系统访问维修时可以先 varyoffvg 再处理磁盘。这个机制比 Linux 的 VG 激活逻辑更容易让人理解硬件维护要做什么。Linux 里没有 varyonvg但vgchange -a y相当于激活。概念迁移的时候用 AIX 这套卷组仓库 逻辑卷切割 物理卷入池的模型去理解 Linux 的vgs、pvs输出会顺畅得多。2.4 LP 与 LV逻辑侧的一体两面LV 是业务能看到的盘。在 AIX 上可以用mklv创建后格式化也可以用crfs直接创建一块带文件系统的文件卷。LV 内部由 LP 组成。LP 大小和 PP 大小一致但 LP 的作用是把逻辑侧的空间计量和物理侧的空间计量解耦。怎么说呢创建逻辑卷时你告诉系统我要 500 个 LP 的空间系统会先在逻辑层分配 500 个 LP然后在物理层给每个 LP 映射 1 个 PP。如果没做镜像一个 LP 对应一个 PP逻辑空间和物理空间一样大。如果做了双份镜像一个 LP 会对应 2 个 PP逻辑空间不变物理占用翻倍。所以 LP 和 PP 之间的映射关系才是 AIX LVM 能实现逻辑大小不变、物理冗余翻倍的关键。当你用lsvg datavg看卷组信息会发现有Used PPs和Free PPs两个指标它统计的是物理分区层面的占用而lsvg -l datavg看到的是每个逻辑卷占了LPs同时会显示PPs。这两列数值在无镜像时相同有镜像时 PPs 会是 LPs 的副本倍数。我在排障时经常先看这两列一旦发现某个 LV 的 PPs 明显大于 LPs第一反应就是这个卷是不是带着镜像。2.5 一个直观的计算例子假设卷组 datavg 由两块 64GB 的裸盘组成创建卷组时指定 PP 为 8MB。那么每块 PV 有 8192 个 PP卷组一共 16384 个 PP。现在要在 datavg 里创建一个 64GB 的逻辑卷不做镜像需要至少 8192 个 LP每个 LP 映射到 8MB 的 PP总物理占用 64GB。如果业务要求给这个逻辑卷做双份镜像LP 数还是 8192但每个 LP 需要映射 2 个 PP总物理占用变成 128GB。此时卷组里依然有剩下的 PPs 可以分配但总量只够再切一个 64GB 的无镜像逻辑卷。把 LPs 和 PPs 分开统计后容量规划就变成了逻辑容量按 LP 数算物理容量按 PP 数算镜像会放大物理占用。这个例子很小但足够说明一个问题在 AIX 环境里做容量规划不能只看卷组还剩多少空间要看它统计的是 LP 视角还是 PP 视角。否则你以为还能再扩 80GB实际上镜像卷已经把底层 PP 耗得差不多了。3. AIX 的 PP/LP 和 Linux 的 PE/LE 不是一回事3.1 Linux LVM 的三层模型更简单也够用Linux 的 LVM2 核心模型只有 PV、VG、LV 三层。物理卷内部以 PEPhysical Extent物理扩展为最小分配单位默认大小 4MiB创建 VG 时可调。逻辑卷由 LELogical Extent逻辑扩展组成正常情况下一个 LE 映射一个 PE一比一对应。所以用 Linux 的朋友看lvs输出只会看到 LV 的大小不会在逻辑卷内部看到一个独立的LP 数。创建逻辑卷时指定大小就好-L 100G就是 100GB-l 80是按 80 个 LE 来切后者很少用。PE 的大小决定了分配的粒度比如默认 4MiB 时100GB 的逻辑卷实际上由 25600 个 PE 组成。Linux 也有镜像和条带但实现方式与 AIX 不同。Linux 的镜像在 LVM2 中本质是通过 raid 机制完成lvcreate --type raid1 -m 1或者lvconvert --type raid1。底层它依然用 PE 做资源分配逻辑侧没有额外的逻辑分区层。好处是命令直观、输出简单代价是你无法像 AIX 那样直接在 LV 创建时用copies参数轻量定义镜像副本数需要额外理解 raid1 的内部映射关系。3.2 AIX 的 LP 多出来的那一层换来了什么AIX 把 PP 和 LP 分成两层核心目的是物理层的灵活布局。同一份逻辑数据在物理盘上可以放 1 份、2 份甚至 3 份副本而逻辑侧的 LP 数量保持不变。这个设计让镜像、条带化、跨 PV 分配等都变成了物理映射策略逻辑卷本身不必变化。举个例子一个 100GB 的 AIX 逻辑卷可以把它做成双份镜像两个副本分布在两个不同的 PV 上。此时若某一块 PV 出现故障系统可以通过镜像副本继续提供服务管理员再想办法把故障盘换成新盘、重新同步镜像。这种机制对数据库这类不能接受长时间业务中断的场景非常有价值。AIX 之所以长期运行在核心生产系统上这个成熟度很高的卷管理能力是重要原因之一。反过来说LP 这层也会带来学习成本和管理复杂度。初学者看到lsvg -l里的 LPs、PPs 两列经常会懵创建逻辑卷时的mklv -y applv -t jfs2 datavg 100M和 Linux 的lvcreate参数习惯也完全不同。可一旦理解了LP 管逻辑刻度、PP 管物理刻度、映射关系由 LVM 维护这个核心所有输出都能对上。3.3 关键差异对照表维度AIX LVMLinux LVM层次PV → PP → VG → LP → LVPV → PE → VG → LE → LV最小物理单元PPPhysical PartitionPEPhysical Extent最小逻辑单元LPLogical PartitionLP 与 PP 映射不一定 1:1LELogical ExtentLE 与 PE 基本 1:1默认单元大小创建卷组时指定常见 4MB/8MB默认 4MiB创建卷组时可调镜像方式创建 LV 时指定 copies 副本数通过 raid1/镜像类型实现创建后转换查看命令lsvg, lspv, lsvg -l, lsvg -pvgs, pvs, lvs, pvdisplay, vgdisplay激活/停用varyonvg / varyoffvgvgchange -a y / vgchange -a n适用场景AIX 小型机核心生产库x86 服务器、虚拟化、云主机这张表是我自己记忆两种体系时最常用的速查。Linux LVM 也有快照、精简配置等功能AIX 在部分高级特性上的实现方式不同但用表里这套主干去对应日常使用已经足够。4. 实战从一块裸盘到可用的文件系统4.1 环境准备与常用查看命令不管 Linux 还是 AIX动手之前先把当前状态摸清楚。Linux 上先用lsblk看新增磁盘的盘符和容量认准/dev/sdb这类设备名然后用pvs、vgs、lvs快速浏览现有卷组剩余空间避免把新盘加到错误的卷组里。AIX 上对应的流程是lsdev -Cc disk查看系统识别到的物理卷lspv查看每个 hdisk 是否已经被分配给某个 VGlsvg -o列出当前已激活的卷组。如果你拿到一台存量很大的机器lsvg -l datavg能一次性列出该卷组下所有逻辑卷和对应的 LP/PP 占用是排查空间问题的首选命令。这个先看清再动手的习惯比任何一条命令都重要。我见过不少同事拿到新盘就直接pvcreatevgcreate结果把本应并入业务卷组的新盘单独建成了一个空卷组或者反过来想加盘却加错了卷组。多敲一条查看命令五秒钟的事能省下后面一个小时的回滚。4.2 Linux 路线pvcreate / vgcreate / lvcreate 串联下面这组命令在大多数环境里可以正常跑。假设新增设备是/dev/sdb要做成一个卷组data_vg然后从里面切一个 100G 逻辑卷挂到/data。# 1. 查看新盘 lsblk /dev/sdb # 2. 创建物理卷 pvcreate /dev/sdb # 3. 创建卷组名字叫 data_vg vgcreate data_vg /dev/sdb # 4. 创建逻辑卷 app_lv大小 100G从 data_vg 里切 lvcreate -n app_lv -L 100G data_vg # 5. 格式化并挂载 mkfs.xfs /dev/data_vg/app_lv mkdir -p /data mount /dev/data_vg/app_lv /data # 6. 验证 pvs vgs lvs df -h /data有一点要特别提醒如果将来还要扩容建议先把卷组预先做好富余空间或者预留一块备用 PV。因为lvcreate用完 VG 全部空间后LV 大小就顶到天想扩就得先做vgextend再加新 PV步骤不复杂但需要维护窗口。不如一开始就把 VG 做大一点LV 按实际需求切后续靠lvextend和xfs_growfs在线扩展。4.3 AIX 路线mkvg / mklv / crfs 的标准姿势AIX 上也分两步创建卷组和创建文件系统。假设新增物理卷是hdisk1准备把 PP 设为 8MB卷组名datavg再从里面创建 JFS2 文件系统挂到/data。# 1. 查看磁盘 lsdev -Cc disk # 2. 创建卷组 datavgPP 大小 8MB mkvg -y datavg -s 8 hdisk1 # 3. 创建逻辑卷 applv类型 jfs2挂载点 /data crfs -v jfs2 -g datavg -m /data -A yes -a size80M # 4. 验证 lsvg datavg lsvg -l datavg df -g /data这里解释一下-a size80M的坑在 AIX 里给 JFS2 文件系统指定大小时80M 指的是 80MB但文件系统最终能用的空间会略小于这个值系统日志和元数据会占用一小部分。如果你在 crfs 时用卷组剩多少就指定多少系统可能提示空间不足。稳妥做法是留出 5% 到 10% 的余量。如果只想建裸逻辑卷不挂文件系统用mklv# 创建 100MB 的逻辑卷 app_lv类型 jfs2 mklv -y app_lv -t jfs2 datavg 100M100M也可以写成 LP 个数比如要 50 个 LPPP 为 8MB 时相当于 400MB直接写mklv -y app_lv -t jfs2 datavg 50。AIX 的很多命令同时支持按大小和按分区个数指定掌握两套写法看别人脚本时就不容易懵。4.4 扩容场景的两套操作对照扩容是日常最高频的变更。Linux 上如果卷组空间不够先加 PVvgextend data_vg /dev/sdc lvextend -L 50G /dev/data_vg/app_lv xfs_growfs /data # xfs 文件系统ext4 用 resize2fsAIX 上的迁移思路一样命令换成extendvg datavg hdisk2 chfs -a size50G /dataextendvg相当于 Linux 的vgextendchfs同时扩展文件和文件系统不需要先单独扩 LV。AIX 里如果想精确调整某个逻辑卷本身的大小也有chlv一类命令但日常文件系统扩容用chfs更安全它会自动帮你处理好挂载点。这里有两条经验第一扩容前最好先快照或备份至少要对关键卷组执行一次备份或记录lsvg -l、lspv输出出现问题可以快速对照。第二在 AIX 里扩文件系统时注意-a size50G的加号不能漏。漏掉加号chfs -a size50G /data会把文件系统严格设定为 50GB如果当前已经 80GB结果很可能是灾难性的。4.5 在线迁移和条带化的进阶用法卷管理和裸分区相比最大的优势就是数据可以搬家。Linux 下pvmove可以把一个 PV 上所有 PE 搬到另一个 PV替换磁盘、调整磁盘布局时非常好用# 把 /dev/sdb 上的数据全部搬到 /dev/sdc pvmove /dev/sdb /dev/sdcAIX 有对应的migratepv可以把指定逻辑卷的数据从一个 PV 挪到另一个 PV# 把 datavg 卷组里 hdisk1 上属于 applv 的空间迁到 hdisk2 migratepv -l applv hdisk1 hdisk2还有一个容易忽略的点在 AIX 里创建逻辑卷时可以指定条带化把连续数据分散到多个 PV 上提升并行读写能力。方式是在mklv时加-S参数比如# 在 hdisk1 和 hdisk2 上创建 200MB 逻辑卷 app_stripe按 64KB 条带 mklv -y app_stripe -t jfs2 -S 64K datavg 200M hdisk1 hdisk2条带化不是银弹。它解决的问题是单盘 I/O 瓶颈但也会让单个逻辑卷的可靠性依赖所有参与条带的盘。只要其中一块盘故障整个卷的数据都可能受影响除非配上镜像或 RAID。我的习惯是临时性、性能敏感且允许重做的卷可以条带化核心数据库卷要么靠存储阵列自身的 RAID 保证数据安全要么在 AIX 层用副本 条带组合而不是只做一层条带。5. 维护期踩过的坑和现在沿用至今的检查清单5.1 PV 掉线后不能慌恢复思路要分层存储最怕的是物理卷掉线。Linux 环境下你可能会看到pvs里出现 unknown device 字样vgs显示卷组状态异常。很多人的第一反应是直接vgreduce --removemissing把失去的 PV 从卷组里摘掉。但如果旧盘还在、只是因为临时链路问题掉线直接移除会让数据丢失风险变大。正确思路是分三步走。第一步用pvscan、pvs确认几块 PV 在线、几块离线能读到的先读出来。第二步加一块替代 PV 进卷组用pvmove把仍然可读的 PE 迁到健康 PV 上如果旧盘已经完全损坏再考虑迁移其他正常 PV 到新盘。第三步确认数据迁移结束后再执行vgreduce --removemissing data_vg最后检查文件系统状态并补做备份。AIX 场景也类似磁盘故障时卷组里会出现STALE标记的 PP。系统会尽量从镜像副本恢复这时通常用syncvg -v datavg把陈旧数据重新同步一遍来消除冲突如果某块盘彻底坏了会用replacepv把旧盘替换成新盘再同步镜像。两条路径看似命令不同核心原则一致能先恢复数据就不要急着物理性移除移除之前必须确认没有可用副本可以同步。5.2 命名、PP 大小和镜像三个高频翻车点先说命名。卷组、逻辑卷的名字一旦上线改起来很痛苦。在 AIX 里卷组名会出现在/dev下比如datavg对应/dev/datavg。命名用_vg、_lv这种带后缀的规则比拼音缩写或者随意编号要有可读性得多。我见过一台机器上出现zz_vg、test1、new1混着来的情况三年后没人能说清哪个卷是干什么的。再说 PP 大小。很多新手在mkvg时为图省事把 PP 设成 256MB 甚至 1GB。对大文件、大分区需求来说这点够用但一旦要建几十个小逻辑卷或者做精细扩容LP 个数会非常尴尬。反过来PP 太小比如 1MB在 10TB 级磁盘上会产生大量 PP 条目元数据操作和扫描速度都会受影响。合理做法是根据卷组未来最大卷容量倒推让单卷的 LP 数落在几千到几万之间通常不会错。最后是镜像。AIX 里建议对核心数据卷创建时直接指定副本数而不是事后补。倒不是因为事后不行而是镜像同步过程会占用资源在线转换时如果业务压力很大可能影响性能。Linux 的 raid1 转换也有类似问题。我在生产变更时习惯把镜像同步安排在业务低峰期并提前练习模拟一块盘故障后靠副本恢复的预案。5.3 我每次变更前必查的清单下面这份清单来自我这些年的维护习惯不涉及某个厂商的封闭界面Linux 和 AIX 都适用记录变更前状态Linux 保存pvs、vgs、lvs输出AIX 保存lsvg -l、lsvg -p、lspv输出留到一个临时文件里。确认卷组里有足够的可用空间别只看卷组总空间要看Free PPs或者 VG Free 这一列不要被镜像副本数迷惑。确认目标 LV 的挂载点AIX 里lsvg -l会显示每个 LV 对应的 MOUNT 点Linux 用df -h和findmnt双重确认避免扩错逻辑卷。变更前备份或快照数据库卷如果允许备份最新归档文件服务至少做一次快照不确定时宁可不扩先和业务确认。变更后验证df -h确认新容量生效pvs/vgs/lvs或lsvg -l确认没有异常状态同时观察系统日志里是否有 I/O 报错。留回滚预案能扩的卷通常也能缩但缩卷风险明显更大。我的经验是能扩就不缩缩卷必须先在测试环境完整演练一遍。这份清单就像汽车的后视镜不是为了让你开得更快而是在变道的时候少撞一次。5.4 PV、LP 这些缩写一出场就有歧义先对齐语境再动手最后聊一个很容易被忽略的现实问题VG、PV、PP、LV、LP 这些缩写并不是存储领域的专利。在互联网运营语境里PV 是 Page View也就是页面浏览量做数据分析的朋友天天都在谈日 PV、月 PV在算法和数学优化里LP 是 Linear Programming线性规划搜 LP 波形 的时候还可能碰到示波器里的 LP 信号概念。所以当你在一台服务器上看到lspv、lsvg时先确认自己是在存储卷管理语境里再拿这套逻辑去套。尤其和业务方沟通时对方说我看今天 PV 涨了很多你千万先问清楚是页面访问量还是物理卷在线状态不然会闹出跨语境的乌龙。技术拼的是基本功但沟通拼的是对齐上下文——这一点在缩写满天飞的基础设施领域尤其要命。 AIX与Linux LVM逻辑卷管理全面解析
1. 一套缩写差点让我在扩容当晚翻车1.1 初次面对这五个缩写时的真实场景刚转做系统运维那阵我接手了一台运行着核心业务的 AIX 小型机。业务方晚上七点提了扩容工单数据目录剩余空间不到 5%希望当晚完成翻倍。我那时候对 Linux LVM 已经有了点使用基础脑子里默认的计划格外清晰——加一块盘做成 PV塞进 VG再把 LV 撑大最后 resize 文件系统。结果登录机子之后命令完全不对路。pvcreate不存在lsvg倒是有可我看不懂输出里那些 LP、PP、VGSTATE、VARYON 到底在说什么。最尴尬的是我连该扩的是LP还是PP都没想明白下mklv命令时差点把卷组可用分区算错。最后靠同事远程指导按先加物理卷、再扩展卷组、再改逻辑卷大小、再扩文件系统的顺序一步步补完才没造成业务中断。那次经历给我留下非常深的印象VG、PV、PP、LV、LP 这五个缩写不是同一套体系里的五胞胎而是层层递进的五层存储架构。少理解任何一层关键时刻都会出错。1.2 这五个缩写解决的是同一个核心问题把这些缩写背后的问题翻译成大白话怎么把一个物理硬盘的能力变成业务系统随时可以调整大小的逻辑盘。物理硬盘买回来就那么大分区一改就要动业务实在太僵化。LVM 的思路是在物理硬盘和文件系统之间增加一个抽象的中间层让空间可以跨盘聚合、在线伸缩、动态迁移。PV、PP、VG、LV、LP 就是这个中间层在不同尺度上的零件。PVPhysical Volume物理卷物理硬盘在被 LVM 收纳后的身份。PPPhysical Partition物理分区AIX 里物理卷上空间分配的最小单位。VGVolume Group卷组多个物理卷聚合成的资源池。LVLogical Volume逻辑卷从资源池里切出来、真正给业务使用的逻辑盘。LPLogical Partition逻辑分区逻辑卷内部的基本组成单位负责把逻辑空间映射回物理空间。需要说明的是这套带 PP 和 LP 的叫法是 AIX 体系里的标准说法。Linux 的 LVM 简化了一些没有 LP 这一层分配单位叫 PE物理扩展和 LE逻辑扩展映射基本是一比一。两种体系的核心思想一样但细节差别会直接影响命令和排查思路所以后面我专门用一整章做对比。1.3 什么样的人需要把这套体系吃透第一类是最直接受益的AIX 小型机管理员日常做卷组、逻辑卷、文件系统扩容、镜像和故障恢复全部绕不开这五个词。第二类是从 Linux 转过来或者两种平台都要维护的运维工程师理解了 AIX 的 PP/LP再回看 Linux 的 LVM 会非常轻松。第三类是云环境里的后端开发和存储规划人员虽然平时面对的是块存储、云盘和卷但真正要理解为什么一个卷可以先在线扩容再重新挂载底层依然是这套物理卷、卷组、逻辑卷的模型。这篇文章不会只讲概念。每一章都会给出命令走查、真实场景里的排查思路以及我在维护环境里总结的检查清单。看完可以直接拿命令套路去自己的实验环境里试一遍再对照手册理解参数效率会高很多。2. 从物理盘到逻辑卷把 VG、PV、PP、LV、LP 按层级摆顺2.1 PV物理卷是存储世界的地基在 AIX 里PV 通常对应一个hdisk设备它可能是一块物理磁盘、磁盘阵列中划分的 LUN或者虚拟化平台映射出来的 vdisk。一个 PV 被纳入 LVM 管理前需要先初始化相当于给这块盘打上 LVM 的识别标签记录盘上有哪些 PP、哪些 PP 已分配、哪些还没分配这些信息保存在盘上的固定位置。Linux 里这一步是pvcreateAIX 里通常在创建卷组时由mkvg顺手完成不需要单独执行。PV 的一个关键特性是它被划入某个 VG 之后就不再以一整块盘为单位去参与分配而是以 PP 为单位。所以哪怕两个 PV 大小不一样、来自不同厂商只要进同一个 VG它们的地盘就能被统一调度。这一点和 Linux LVM 非常接近底层细节被隐藏上层只看到卷组里有多少可用空间。我见过的常见误区是有人以为 PV 等于盘上的某个分区比如/dev/sda1。实际上在传统 LVM 里PV 可以建立在整块盘上也可以建立在独立分区上在 AIX 里更常见的是直接用整个 hdisk。分区和 PV 是两回事分区表是操作系统的磁盘分区概念PV 是 LVM 资源池的入池单位。2.2 PPAIX 分配空间的最小刻度PP 是 AIX LVM 里最有特色的概念。它把 PV 这块物理卷进一步切成固定大小的格子卷组内所有 PV 的 PP 大小必须一致。PP 大小在创建卷组时确定比如mkvg -s 8表示每个 PP 是 8MB。之后如果要在卷组里创建逻辑卷空间需求会被换算成需要多少个 LPLP 再指向具体哪个 PP。为什么要有这个格子因为在没有 PP 抽象之前一块盘上的空间要么被整个分区占用要么用非常复杂的起止扇区记录来管理扩容、缩容、镜像都非常痛苦。有了固定大小的 PPLVM 做三件事都很方便一是分配空间时只要数格子二是做条带化时可以在不同 PV 上取固定格子交替排布三是做镜像时能轻松维护同一份逻辑数据对应两个物理格子的映射关系。PP 大小的选择是个权衡太小映射表细粒度灵活但管理开销和元数据占用更高太大映射表粗管理省事但逻辑卷扩容时会浪费空间而且一些场景下差一点就够用的小卷会特别尴尬。我维护的 AIX 环境里业务数据卷组常用 4MB 或 8MB 的 PP如果是大数据平台一类的大单体文件系统会考虑 64MB 或更高。这个没有绝对标准取决于你的卷数量级和增长节奏。2.3 VG把一堆 PV 收纳成一个资源池卷组是整个 LVM 的调度中枢。一个 VG 可以包含一个或多个 PVVG 建立后所有 PV 上的 PP 被统一编号管理形成一个跨磁盘的大仓库。业务系统看到的逻辑卷全部从 VG 里切至于这个逻辑卷的底层落在哪块盘上由 LVM 根据映射策略决定业务和文件系统都不需要关心。查 VG 状态AIX 里用lsvg单个 VG 的详细情况用lsvg datavg查看某个 VG 里有哪几个 PV 用lsvg -p datavg。输出里常见VG STATE为active或inactive这对应 AIX 的卷组已激活/未激活概念。卷组必须先 varyonvg 激活里面的逻辑卷才能被系统访问维修时可以先 varyoffvg 再处理磁盘。这个机制比 Linux 的 VG 激活逻辑更容易让人理解硬件维护要做什么。Linux 里没有 varyonvg但vgchange -a y相当于激活。概念迁移的时候用 AIX 这套卷组仓库 逻辑卷切割 物理卷入池的模型去理解 Linux 的vgs、pvs输出会顺畅得多。2.4 LP 与 LV逻辑侧的一体两面LV 是业务能看到的盘。在 AIX 上可以用mklv创建后格式化也可以用crfs直接创建一块带文件系统的文件卷。LV 内部由 LP 组成。LP 大小和 PP 大小一致但 LP 的作用是把逻辑侧的空间计量和物理侧的空间计量解耦。怎么说呢创建逻辑卷时你告诉系统我要 500 个 LP 的空间系统会先在逻辑层分配 500 个 LP然后在物理层给每个 LP 映射 1 个 PP。如果没做镜像一个 LP 对应一个 PP逻辑空间和物理空间一样大。如果做了双份镜像一个 LP 会对应 2 个 PP逻辑空间不变物理占用翻倍。所以 LP 和 PP 之间的映射关系才是 AIX LVM 能实现逻辑大小不变、物理冗余翻倍的关键。当你用lsvg datavg看卷组信息会发现有Used PPs和Free PPs两个指标它统计的是物理分区层面的占用而lsvg -l datavg看到的是每个逻辑卷占了LPs同时会显示PPs。这两列数值在无镜像时相同有镜像时 PPs 会是 LPs 的副本倍数。我在排障时经常先看这两列一旦发现某个 LV 的 PPs 明显大于 LPs第一反应就是这个卷是不是带着镜像。2.5 一个直观的计算例子假设卷组 datavg 由两块 64GB 的裸盘组成创建卷组时指定 PP 为 8MB。那么每块 PV 有 8192 个 PP卷组一共 16384 个 PP。现在要在 datavg 里创建一个 64GB 的逻辑卷不做镜像需要至少 8192 个 LP每个 LP 映射到 8MB 的 PP总物理占用 64GB。如果业务要求给这个逻辑卷做双份镜像LP 数还是 8192但每个 LP 需要映射 2 个 PP总物理占用变成 128GB。此时卷组里依然有剩下的 PPs 可以分配但总量只够再切一个 64GB 的无镜像逻辑卷。把 LPs 和 PPs 分开统计后容量规划就变成了逻辑容量按 LP 数算物理容量按 PP 数算镜像会放大物理占用。这个例子很小但足够说明一个问题在 AIX 环境里做容量规划不能只看卷组还剩多少空间要看它统计的是 LP 视角还是 PP 视角。否则你以为还能再扩 80GB实际上镜像卷已经把底层 PP 耗得差不多了。3. AIX 的 PP/LP 和 Linux 的 PE/LE 不是一回事3.1 Linux LVM 的三层模型更简单也够用Linux 的 LVM2 核心模型只有 PV、VG、LV 三层。物理卷内部以 PEPhysical Extent物理扩展为最小分配单位默认大小 4MiB创建 VG 时可调。逻辑卷由 LELogical Extent逻辑扩展组成正常情况下一个 LE 映射一个 PE一比一对应。所以用 Linux 的朋友看lvs输出只会看到 LV 的大小不会在逻辑卷内部看到一个独立的LP 数。创建逻辑卷时指定大小就好-L 100G就是 100GB-l 80是按 80 个 LE 来切后者很少用。PE 的大小决定了分配的粒度比如默认 4MiB 时100GB 的逻辑卷实际上由 25600 个 PE 组成。Linux 也有镜像和条带但实现方式与 AIX 不同。Linux 的镜像在 LVM2 中本质是通过 raid 机制完成lvcreate --type raid1 -m 1或者lvconvert --type raid1。底层它依然用 PE 做资源分配逻辑侧没有额外的逻辑分区层。好处是命令直观、输出简单代价是你无法像 AIX 那样直接在 LV 创建时用copies参数轻量定义镜像副本数需要额外理解 raid1 的内部映射关系。3.2 AIX 的 LP 多出来的那一层换来了什么AIX 把 PP 和 LP 分成两层核心目的是物理层的灵活布局。同一份逻辑数据在物理盘上可以放 1 份、2 份甚至 3 份副本而逻辑侧的 LP 数量保持不变。这个设计让镜像、条带化、跨 PV 分配等都变成了物理映射策略逻辑卷本身不必变化。举个例子一个 100GB 的 AIX 逻辑卷可以把它做成双份镜像两个副本分布在两个不同的 PV 上。此时若某一块 PV 出现故障系统可以通过镜像副本继续提供服务管理员再想办法把故障盘换成新盘、重新同步镜像。这种机制对数据库这类不能接受长时间业务中断的场景非常有价值。AIX 之所以长期运行在核心生产系统上这个成熟度很高的卷管理能力是重要原因之一。反过来说LP 这层也会带来学习成本和管理复杂度。初学者看到lsvg -l里的 LPs、PPs 两列经常会懵创建逻辑卷时的mklv -y applv -t jfs2 datavg 100M和 Linux 的lvcreate参数习惯也完全不同。可一旦理解了LP 管逻辑刻度、PP 管物理刻度、映射关系由 LVM 维护这个核心所有输出都能对上。3.3 关键差异对照表维度AIX LVMLinux LVM层次PV → PP → VG → LP → LVPV → PE → VG → LE → LV最小物理单元PPPhysical PartitionPEPhysical Extent最小逻辑单元LPLogical PartitionLP 与 PP 映射不一定 1:1LELogical ExtentLE 与 PE 基本 1:1默认单元大小创建卷组时指定常见 4MB/8MB默认 4MiB创建卷组时可调镜像方式创建 LV 时指定 copies 副本数通过 raid1/镜像类型实现创建后转换查看命令lsvg, lspv, lsvg -l, lsvg -pvgs, pvs, lvs, pvdisplay, vgdisplay激活/停用varyonvg / varyoffvgvgchange -a y / vgchange -a n适用场景AIX 小型机核心生产库x86 服务器、虚拟化、云主机这张表是我自己记忆两种体系时最常用的速查。Linux LVM 也有快照、精简配置等功能AIX 在部分高级特性上的实现方式不同但用表里这套主干去对应日常使用已经足够。4. 实战从一块裸盘到可用的文件系统4.1 环境准备与常用查看命令不管 Linux 还是 AIX动手之前先把当前状态摸清楚。Linux 上先用lsblk看新增磁盘的盘符和容量认准/dev/sdb这类设备名然后用pvs、vgs、lvs快速浏览现有卷组剩余空间避免把新盘加到错误的卷组里。AIX 上对应的流程是lsdev -Cc disk查看系统识别到的物理卷lspv查看每个 hdisk 是否已经被分配给某个 VGlsvg -o列出当前已激活的卷组。如果你拿到一台存量很大的机器lsvg -l datavg能一次性列出该卷组下所有逻辑卷和对应的 LP/PP 占用是排查空间问题的首选命令。这个先看清再动手的习惯比任何一条命令都重要。我见过不少同事拿到新盘就直接pvcreatevgcreate结果把本应并入业务卷组的新盘单独建成了一个空卷组或者反过来想加盘却加错了卷组。多敲一条查看命令五秒钟的事能省下后面一个小时的回滚。4.2 Linux 路线pvcreate / vgcreate / lvcreate 串联下面这组命令在大多数环境里可以正常跑。假设新增设备是/dev/sdb要做成一个卷组data_vg然后从里面切一个 100G 逻辑卷挂到/data。# 1. 查看新盘 lsblk /dev/sdb # 2. 创建物理卷 pvcreate /dev/sdb # 3. 创建卷组名字叫 data_vg vgcreate data_vg /dev/sdb # 4. 创建逻辑卷 app_lv大小 100G从 data_vg 里切 lvcreate -n app_lv -L 100G data_vg # 5. 格式化并挂载 mkfs.xfs /dev/data_vg/app_lv mkdir -p /data mount /dev/data_vg/app_lv /data # 6. 验证 pvs vgs lvs df -h /data有一点要特别提醒如果将来还要扩容建议先把卷组预先做好富余空间或者预留一块备用 PV。因为lvcreate用完 VG 全部空间后LV 大小就顶到天想扩就得先做vgextend再加新 PV步骤不复杂但需要维护窗口。不如一开始就把 VG 做大一点LV 按实际需求切后续靠lvextend和xfs_growfs在线扩展。4.3 AIX 路线mkvg / mklv / crfs 的标准姿势AIX 上也分两步创建卷组和创建文件系统。假设新增物理卷是hdisk1准备把 PP 设为 8MB卷组名datavg再从里面创建 JFS2 文件系统挂到/data。# 1. 查看磁盘 lsdev -Cc disk # 2. 创建卷组 datavgPP 大小 8MB mkvg -y datavg -s 8 hdisk1 # 3. 创建逻辑卷 applv类型 jfs2挂载点 /data crfs -v jfs2 -g datavg -m /data -A yes -a size80M # 4. 验证 lsvg datavg lsvg -l datavg df -g /data这里解释一下-a size80M的坑在 AIX 里给 JFS2 文件系统指定大小时80M 指的是 80MB但文件系统最终能用的空间会略小于这个值系统日志和元数据会占用一小部分。如果你在 crfs 时用卷组剩多少就指定多少系统可能提示空间不足。稳妥做法是留出 5% 到 10% 的余量。如果只想建裸逻辑卷不挂文件系统用mklv# 创建 100MB 的逻辑卷 app_lv类型 jfs2 mklv -y app_lv -t jfs2 datavg 100M100M也可以写成 LP 个数比如要 50 个 LPPP 为 8MB 时相当于 400MB直接写mklv -y app_lv -t jfs2 datavg 50。AIX 的很多命令同时支持按大小和按分区个数指定掌握两套写法看别人脚本时就不容易懵。4.4 扩容场景的两套操作对照扩容是日常最高频的变更。Linux 上如果卷组空间不够先加 PVvgextend data_vg /dev/sdc lvextend -L 50G /dev/data_vg/app_lv xfs_growfs /data # xfs 文件系统ext4 用 resize2fsAIX 上的迁移思路一样命令换成extendvg datavg hdisk2 chfs -a size50G /dataextendvg相当于 Linux 的vgextendchfs同时扩展文件和文件系统不需要先单独扩 LV。AIX 里如果想精确调整某个逻辑卷本身的大小也有chlv一类命令但日常文件系统扩容用chfs更安全它会自动帮你处理好挂载点。这里有两条经验第一扩容前最好先快照或备份至少要对关键卷组执行一次备份或记录lsvg -l、lspv输出出现问题可以快速对照。第二在 AIX 里扩文件系统时注意-a size50G的加号不能漏。漏掉加号chfs -a size50G /data会把文件系统严格设定为 50GB如果当前已经 80GB结果很可能是灾难性的。4.5 在线迁移和条带化的进阶用法卷管理和裸分区相比最大的优势就是数据可以搬家。Linux 下pvmove可以把一个 PV 上所有 PE 搬到另一个 PV替换磁盘、调整磁盘布局时非常好用# 把 /dev/sdb 上的数据全部搬到 /dev/sdc pvmove /dev/sdb /dev/sdcAIX 有对应的migratepv可以把指定逻辑卷的数据从一个 PV 挪到另一个 PV# 把 datavg 卷组里 hdisk1 上属于 applv 的空间迁到 hdisk2 migratepv -l applv hdisk1 hdisk2还有一个容易忽略的点在 AIX 里创建逻辑卷时可以指定条带化把连续数据分散到多个 PV 上提升并行读写能力。方式是在mklv时加-S参数比如# 在 hdisk1 和 hdisk2 上创建 200MB 逻辑卷 app_stripe按 64KB 条带 mklv -y app_stripe -t jfs2 -S 64K datavg 200M hdisk1 hdisk2条带化不是银弹。它解决的问题是单盘 I/O 瓶颈但也会让单个逻辑卷的可靠性依赖所有参与条带的盘。只要其中一块盘故障整个卷的数据都可能受影响除非配上镜像或 RAID。我的习惯是临时性、性能敏感且允许重做的卷可以条带化核心数据库卷要么靠存储阵列自身的 RAID 保证数据安全要么在 AIX 层用副本 条带组合而不是只做一层条带。5. 维护期踩过的坑和现在沿用至今的检查清单5.1 PV 掉线后不能慌恢复思路要分层存储最怕的是物理卷掉线。Linux 环境下你可能会看到pvs里出现 unknown device 字样vgs显示卷组状态异常。很多人的第一反应是直接vgreduce --removemissing把失去的 PV 从卷组里摘掉。但如果旧盘还在、只是因为临时链路问题掉线直接移除会让数据丢失风险变大。正确思路是分三步走。第一步用pvscan、pvs确认几块 PV 在线、几块离线能读到的先读出来。第二步加一块替代 PV 进卷组用pvmove把仍然可读的 PE 迁到健康 PV 上如果旧盘已经完全损坏再考虑迁移其他正常 PV 到新盘。第三步确认数据迁移结束后再执行vgreduce --removemissing data_vg最后检查文件系统状态并补做备份。AIX 场景也类似磁盘故障时卷组里会出现STALE标记的 PP。系统会尽量从镜像副本恢复这时通常用syncvg -v datavg把陈旧数据重新同步一遍来消除冲突如果某块盘彻底坏了会用replacepv把旧盘替换成新盘再同步镜像。两条路径看似命令不同核心原则一致能先恢复数据就不要急着物理性移除移除之前必须确认没有可用副本可以同步。5.2 命名、PP 大小和镜像三个高频翻车点先说命名。卷组、逻辑卷的名字一旦上线改起来很痛苦。在 AIX 里卷组名会出现在/dev下比如datavg对应/dev/datavg。命名用_vg、_lv这种带后缀的规则比拼音缩写或者随意编号要有可读性得多。我见过一台机器上出现zz_vg、test1、new1混着来的情况三年后没人能说清哪个卷是干什么的。再说 PP 大小。很多新手在mkvg时为图省事把 PP 设成 256MB 甚至 1GB。对大文件、大分区需求来说这点够用但一旦要建几十个小逻辑卷或者做精细扩容LP 个数会非常尴尬。反过来PP 太小比如 1MB在 10TB 级磁盘上会产生大量 PP 条目元数据操作和扫描速度都会受影响。合理做法是根据卷组未来最大卷容量倒推让单卷的 LP 数落在几千到几万之间通常不会错。最后是镜像。AIX 里建议对核心数据卷创建时直接指定副本数而不是事后补。倒不是因为事后不行而是镜像同步过程会占用资源在线转换时如果业务压力很大可能影响性能。Linux 的 raid1 转换也有类似问题。我在生产变更时习惯把镜像同步安排在业务低峰期并提前练习模拟一块盘故障后靠副本恢复的预案。5.3 我每次变更前必查的清单下面这份清单来自我这些年的维护习惯不涉及某个厂商的封闭界面Linux 和 AIX 都适用记录变更前状态Linux 保存pvs、vgs、lvs输出AIX 保存lsvg -l、lsvg -p、lspv输出留到一个临时文件里。确认卷组里有足够的可用空间别只看卷组总空间要看Free PPs或者 VG Free 这一列不要被镜像副本数迷惑。确认目标 LV 的挂载点AIX 里lsvg -l会显示每个 LV 对应的 MOUNT 点Linux 用df -h和findmnt双重确认避免扩错逻辑卷。变更前备份或快照数据库卷如果允许备份最新归档文件服务至少做一次快照不确定时宁可不扩先和业务确认。变更后验证df -h确认新容量生效pvs/vgs/lvs或lsvg -l确认没有异常状态同时观察系统日志里是否有 I/O 报错。留回滚预案能扩的卷通常也能缩但缩卷风险明显更大。我的经验是能扩就不缩缩卷必须先在测试环境完整演练一遍。这份清单就像汽车的后视镜不是为了让你开得更快而是在变道的时候少撞一次。5.4 PV、LP 这些缩写一出场就有歧义先对齐语境再动手最后聊一个很容易被忽略的现实问题VG、PV、PP、LV、LP 这些缩写并不是存储领域的专利。在互联网运营语境里PV 是 Page View也就是页面浏览量做数据分析的朋友天天都在谈日 PV、月 PV在算法和数学优化里LP 是 Linear Programming线性规划搜 LP 波形 的时候还可能碰到示波器里的 LP 信号概念。所以当你在一台服务器上看到lspv、lsvg时先确认自己是在存储卷管理语境里再拿这套逻辑去套。尤其和业务方沟通时对方说我看今天 PV 涨了很多你千万先问清楚是页面访问量还是物理卷在线状态不然会闹出跨语境的乌龙。技术拼的是基本功但沟通拼的是对齐上下文——这一点在缩写满天飞的基础设施领域尤其要命。