3par 容量怎么计算的

你看到的3PAR容量页面，其计算逻辑可以概括为一个核心公式：

总物理容量 = 已分配容量 + 可用容量 + 故障容量

而你问的“块”和“系统”，正是“已分配容量”中的两个关键组成部分。根据你提供的数据，这台CF22080的容量构成如下：

 核心概念：什么是“块”与“系统”？

在3PAR的架构中，磁盘空间的管理非常精细，你看到的“块”和“系统”对应着不同的用途。

 “块 (Block)”：存放数据的“仓库”

这是实际用于存储你的业务数据的容量，包含了所有虚拟卷（VV）的用户数据、快照数据和管理空间。

• 空间构成：这部分空间已经包含了RAID校验开销。例如，如果底层磁盘做了RAID 6 (8+2)，那么10块盘的原始容量中，只有8块盘的容量能计入“块”容量，另外2块盘的开销被RAID机制消耗了。

• 精简配置 (Thin Provisioning)：3PAR默认采用精简配置。创建卷时，你指定的是虚拟容量（逻辑大小），而“块”容量反映的是实际物理占用。只有当数据真正写入时，才会从可用空间（Free）中分配物理块。因此，“已分配块容量”通常会小于所有卷的“虚拟容量”总和。

• 一句话理解：“块”就是你真正能用来存数据、已经划走的部分。

 “系统 (System)”：保障稳定的“后备队”

这部分是3PAR为保障系统稳定运行和故障恢复而预留的容量，不存放用户数据。根据社区和官方资料，它主要由以下部分组成：

• 热备空间 (Spare Space)：这是“系统”容量的主要构成。3PAR不指定整块硬盘做热备，而是从所有硬盘中分散预留一部分空间（chunklets） 作为热备。当任何一块硬盘故障时，系统能利用这些分散的备用空间，快速在其他正常硬盘上重建数据。

• 系统开销 (Internal/Admin Space)：用于存放系统自身的元数据，例如CPG（Common Provisioning Group）的管理信息、系统报告日志（System Reporter logging）等。

• 一句话理解：“系统”是3PAR为了能容忍硬盘故障并保持自身管理运转而“预留”的救急空间。

 容量计算逻辑验证

根据3PAR的容量管理原则，我们可以用你图中的数据来验证这个关系：

• 已分配容量 = 块容量 + 系统容量 = 101,056 + 14,414 = 115,470 GiB (与图中数据完全吻合)

• 总物理容量 = 已分配容量 + 可用容量 = 115,470 + 27,570 = 143,040 GiB (与图中数据完全吻合)

这说明图中的数据展示是符合3PAR标准计算逻辑的。

 补充：为什么“已分配”不等于“已使用”？

你可能会发现，在“块”容量中，还分“已分配”和“已使用”。这源于3PAR的精简配置（Thin Provisioning） 特性：

• 已分配 (Allocated)：指已经划给卷的物理空间。

• 已使用 (Used)：指卷中实际写入了数据的物理空间。

例如，你创建一个1TB的精简卷，系统会从“可用空间”中划出一部分（比如100GB）作为“已分配”空间，但你可能只写入了10GB数据，那么这10GB就是“已使用”空间。剩余的90GB“已分配”空间虽然被预留，但并未真正消耗磁盘，未来可以释放。

 如何查看更多容量细节

如果你想进一步分析，可以在SSH命令行（CLI）中执行以下命令：

1. 查看物理磁盘总容量：showpd -c，可以查看每块物理磁盘的原始容量和可用容量。

2. 查看CPG分配情况：showcpg -d，查看各个CPG（存储池）的详细容量和分配情况。

3. 查看系统空间构成：showsys -space，可以清晰地看到“系统”、“内部”、“备用”等空间的具体数值，让你对预留空间一目了然。

截图信息： 总 SSD：143040GiB；已分配 SSD 容量合计 115470GiB，其中块：101056GiB，系统：14414GiB。

一、两个名词含义（红框【已分配的 SSD 容量】）

1. 块（块容量） 就是业务虚拟卷 VV（Virtual Volume）占用的 SSD 物理空间，也就是给虚拟机 / 数据库 / 业务服务器挂载的块存储卷实际占用的 SSD 空间。

包含：精简卷 / 全量卷、重删压缩后的实际占用、快照空间、副本空间。 就是用户业务真正使用的块存储数据空间。

2. 系统（系统容量） 3PAR 存储系统自身占用的 SSD 空间，不是业务数据。 包含：

• 系统元数据、Chunklet 管理表、CPG 池管理信息
• 控制器 OS、日志、内部数据库
• 内部保留空间、磁盘故障预留 spare 空间、重删 / 压缩的元数据

⚠️这部分是存储底层必须占用，不能分配给业务主机使用。

已分配 SSD 总计 = 块 (业务卷) + 系统 (存储底层占用) = 101056 +14414 =115470GiB，和截图数值一致。

二、整页容量的三层计算逻辑

1. 总 SSD 容量（最左侧饼图） 总SSD = 已分配 + 可用 + 故障

• 总 SSD：143040GiB：所有 SSD 盘裸物理总容量
• 已分配：115470GiB（就是右边红框的总和：业务块 + 系统占用）
• 可用：27570GiB：SSD 还没有分配进 CPG、还可以新建业务卷的空闲物理空间
• 故障：0GiB，无故障盘

⚠️注意：3PAR 是先把磁盘空间划进 CPG 资源池，才叫 “已分配”；不是主机写数据才算分配。哪怕你创建精简卷、主机还没写入任何数据，只要从 CPG 分配了空间，就会计入【块】容量。

2. 区分两个概念

• 已分配 SSD：物理磁盘空间已经被 3PAR 系统接管（要么给业务块卷、要么给系统底层）
• 可用 SSD：SSD 物理盘还没划入 CPG 池，还可以拿来扩容业务卷的物理空间

三、容易踩坑的误区

1. ❌不要把【块】当成主机文件系统里的已用空间 3PAR 的块容量是存储侧物理占用，不是主机里面看到的文件占用。精简卷即使主机没写数据，只要从 CPG 分配空间，就会统计在这里；重删压缩会减少这个物理占用。
2. ❌系统容量不是浪费，是强制底层开销 3PAR 的元数据、spare 预留空间必须占用，SSD 越大，系统占用的空间也会相应变大，无法删除。
3. ❌饼图 88% 含义：在全部已分配 SSD 里面，业务块占 88%，系统占 12%；不是整个存储使用率。

这个 88% 分母是【已分配 115470GiB】，不是总 SSD143040GiB。

四、查看命令行核对（3PAR CLI）

简短总结

红框【已分配 SSD 容量】分为块、系统两部分：

• 块：业务块存储虚拟卷（VV）占用 SSD 物理容量，业务主机挂载的存储；
• 系统：3PAR 存储控制器系统、元数据、内部预留 spare 等底层占用 SSD 空间，不能给业务使用。 计算关系：已分配SSD总量 = 块容量 + 系统容量。 左侧总 SSD 饼图：总 SSD 裸容量 = 已分配 + 可用 + 故障；已分配代表磁盘空间已经被存储接管（业务或系统），可用是还未划入资源池的空闲物理 SSD。图中 88% 是【已分配 SSD 内部占比：业务块占已分配空间的 88%】，不是整台存储使用率。