☰

ZFS 容量使用差异

tag-icon • tag-icon zfsonlinux
ZFS 容量使用差异

我试图理解为什么生产 ZFS 数据集和使用夜间 zfs 发送填充的备份数据集的已用空间存在巨大差异（我保留 30 个每日快照并每晚复制 - 没有其他系统写入或以其他方式访问备份数据集）。双方均未启用压缩和重复数据删除。备份数据集报告使用 315T，而生产仅使用 311T（这两个系统在硬件方面基本上是镜像的）。我的问题是夜间 zfs 发送现在失败了（空间不足）。

后续问题是，是否有明显的解决方法？备份池显示有 10.7T 可用空间，但似乎无法用于数据集，因为它仅报告有 567G 可用空间。如果我要销毁备份池并对生产数据执行完整的 zfs 发送，我们是否希望它完成？我已经销毁了备份数据集上除最近两个快照之外的所有快照，但它没有释放足够的空间来允许新的 zfs 发送。我特意在生产数据集上设置了 312T 的配额，以帮助控制用户，因为他们通常会在接近 100% 满的情况下工作，但似乎配额可能还不够？（备份池/数据集上没有定义配额）

Production system:
# zpool list
NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
data      326T   311T  15.3T         -    44%    95%  1.00x  ONLINE  -

# zfs list
NAME                                                 USED  AVAIL  REFER  MOUNTPOINT
data                                                 311T  5.11T    96K  /data
data/lab                                             311T  1.30T   306T  /data/lab


Backup system:
# zpool list
NAME        SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
backup      326T   315T  10.7T         -     6%    96%  1.00x  ONLINE  -

# zfs list
NAME                                                   USED  AVAIL  REFER  MOUNTPOINT
backup                                                 315T   567G    96K  /backup
backup/lab                                             315T   567G   315T  /backup/lab

答案1

基于输出zdb您的目标（备份）池没有 SLOG 设备。这意味着分配了额外的 ZIL 块里面池常规空间，占用可用空间。虽然主池 SLOG 设备“仅”约为 185GB（对于常规 SLOG 来说太多了），但对目标池的影响可能更大，因为新块会不断分配给 ZIL 工作。此外，这可能导致元块过度分散，总分配空间更多。

编辑：大小差异的另一个可能原因可能与 zfs send/recv 本身有关：默认情况下，它以最大兼容性选项运行，这可能会使接收端稍微膨胀。有关更多信息，您可以查看邮件帖子这里

笔记：上述答案明确假设所有其他事情都是并且相等 - 例如，如果您在源池上暂时启用了压缩，则空间分配与目标池相比将明显不同（如果它从未启用过压缩）。

使固定：我认为现在为备份池添加 SLOG 没什么用；相反，我会调整spa_slop_shift（增加它）以恢复一些重要空间。默认值为 5，请尝试通过发出 将其设置为 6。echo 6 > /sys/module/zfs/parameters/spa_slop_shift后续操作zfs list应报告更多可用空间（使用不分配空间上的更改如图所示zpool list）。

如果您需要更多空间，您可以再次增加spa_slop_shift- 但请务必阅读文档以了解您正在做什么。

相关内容