RAID 后的可用存储

01

标准化字节、TB 和 TiB

驱动器标签和Tungsto目录使用十进制单位：一个TB是1,000,000,000,000字节。一个TiB是1,099,511,627,776字节。因此相同的字节数在TiB中显示为较小的数字。从源字节转换，而不是反复应用四舍五入的百分比，并在工作表的每一列标注其单位。

例如，12 × 16 TB 目录阵列在冗余之前包含 192 TB 原始容量，而 24 × 20 TB 包含 480 TB 原始容量。这些数字不包括单独的 NVMe 启动对。它们是库存事实，而非关于文件系统可见或可写容量的声明。

02

模拟真实拓扑，而不是一行聚合数据

当成员大小不同时，除非所选实现另有说明，否则使用最小的参与设备大小；较大的部分可能无法使用。将启动、缓存、日志、备用和数据设备分开。对于ZFS，识别每个顶层vdev及其冗余。数据在顶层vdev之间条带化，因此一个非冗余vdev可能使原本镜像的池容易受到该单个设备的影响。

简单的奇偶校验公式将 RAIDZ 组近似为数据设备数乘以设备大小，但实际分配取决于记录大小、扇区几何和奇偶校验行为。因此，OpenZFS 将其可用池属性描述为启发式方法，而非精确承诺。

• 打开ZFS池容量属性↗

03

应用容量瀑布

从原始字节开始，减去冗余和任何专用热备盘，然后读取创建的文件系统或池自身的可用属性。从该结果中，保留策略、快照、写时复制行为、临时复制或恢复工作以及应用程序增长所需的空间。不要假设压缩或重复数据删除节省；两者都取决于数据和配置，并且可能从保守预测中消失。

保留两个输出：用于比较布局的理论容量和用于接纳数据的运营容量。第二个应包括由运营商选择的警报阈值和停止接纳阈值。即使最初的算术看起来正确，文件系统填满到最后一个报告的字节也可能会影响维护和恢复。

04

在提交数据之前验证创建的池

创建所选布局后，记录设备成员关系、冗余、健康状况以及实施报告中的可用容量。在 ZFS 上，要区分池级估计和数据集可用性，因为配额、预留和奇偶校验可能导致它们不同。TrueNAS 容量计算器对于规划 ZFS 几何结构很有用，但其输入仍需与实际驱动器、ashift、记录大小、热备盘和预留策略相匹配。

在生产前创建验收记录：原始字节、布局图、计算值、报告值、预留空间、快照策略和备份目标。调查任何无法解释的差距，而不是更改单位直到数字看起来匹配。

05

将容量和恢复分开

较大的可用数字并不能证明设计更安全。在容量结果旁边说明可容忍的设备故障、监控、备用程序、清理或一致性检查策略以及恢复源。RAID 和 ZFS 冗余仍在一个机箱内；它们不能防止删除、泄露或服务器丢失。

预期结果是一个可复现的容量工作表，其他操作员可以根据设备字节数和拓扑重新计算。使用计算器进行初步筛选，然后在提供应用容量之前，用已部署池的观测属性替换其估算值。