☰

zfs zpool dedup stat 似乎非常错误 - 如何解释这些值？

tag-icon • tag-icon zfs deduplication
zfs zpool dedup stat 似乎非常错误 - 如何解释这些值？

我运行一个文件服务器来接收用户容器的备份。两个容器是运行不良的 Docker 系统，其中有数百个几乎相同的目录，没有使用 overlayfs 或 zfs 克隆。（我无法触碰用户的容器来纠正它们的使用，似乎也无法教育它们。）

我认为，作为测试，只需将文件服务器上的备份目标 zfs fs 复制到同一池中新建的 fs 中，但启用 dedup=on。fs 的大小约为 540GB 和 630GB。池和其他 fs 的 Dedup 已关闭（压缩已启用）。

我已经完成复制，但是现在 zpool list 显示整个备份池的 25 TB 数据的重复数据删除率为 2.93 倍 - 而我只为这两个 fs 复制了大约 1.15 TB。

Zpool 列表：

NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
d      30.0T  25.7T  4.27T        -         -    41%    85%  2.92x    ONLINE  -

整个池的 zdb -DD 输出是：

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    3.75M    454G    249G    250G    3.75M    454G    249G    250G
     2     359K   41.0G   38.8G   39.2G     752K   84.9G   80.2G   81.1G
     4    50.1K   4.43G   3.79G   3.94G     242K   21.2G   18.2G   18.9G
     8    37.3K   2.98G   2.62G   2.77G     396K   31.3G   27.6G   29.2G
    16    21.6K   1.63G   1.31G   1.39G     475K   34.9G   27.5G   29.4G
    32    20.5K    918M    699M    854M    1.06M   46.8G   35.7G   44.0G
    64    20.3K   1.07G    851M    991M    1.71M   93.6G   71.4G   82.8G
   128    5.13K    341M    297M    327M     813K   55.3G   47.6G   51.8G
   256    14.7K    725M    493M    592M    6.56M    328G    224G    267G
   512    1.09K   7.44M   6.51M   21.3M     838K   4.80G   4.21G   15.4G
    1K      119    300K    232K   1.88M     188K    427M    347M   2.95G
    2K       22     65K     53K    352K    60.5K    172M    143M    968M
    4K        9     33K   32.5K    144K    49.1K    150M    148M    786M
    8K        3   2.50K   2.50K     48K    36.0K   29.3M   29.3M    576M
   16K        5   2.50K   2.50K     80K     131K   65.7M   65.7M   2.05G
   32K        1    512B    512B     16K    62.8K   31.4M   31.4M   1004M
   64K        1    512B    512B     16K    90.9K   45.4M   45.4M   1.42G
 Total    4.27M    507G    298G    301G    17.1M   1.13T    786G    880G

dedup = 2.93, compress = 1.47, copies = 1.12, dedup * compress / copies = 3.84

（不能在文件系统上运行 zdb -DD，只能在整个池上运行。）

至于实际 fs 上的 used 与 logicalused ，我看到：

d/ntgor4  used                  398G                   -
d/ntgor4  logicalused           542G                   -
d/ntgor5  used                  528G                   -
d/ntgor5  logicalused           629G                   -

因此，根本没有多少节省，但是重复数据删除的值相当高 - 并且直方图表明存在一些较大的节省（特别是在引用的块数中，特别是在 256 个块时）。

读取直方图并检查 PSIZE 和 DSIZE，我假设这仅指那些具有重复数据删除的 fs - 而不是整个池 - 因此 zpool list 的重复数据删除因子也是如此。（除非它在重复数据删除中包含快照？）

有人可以解释一下如何解释这一点以及为什么重复数据删除因子如此之高吗？

答案1

zpool list 中的重复数据删除数字仅适用于具有 DDT（重复数据删除表）的 fs - 池中的所有其他 fs 和磁盘使用情况将被忽略且不计算在内。

在我看来，这是误导。我的 2.93x dedup 仅适用于 ntgor4 和 5 fs。

相关内容