关于 zfs 的内存需求疑问， raid-z2 和 raid-z3 的内存需求是否相同

[muhairen]

总磁盘数量一定的情况下，raid-z2 和 raid-z3 的实际可用空间不同，如果开启去重，他们对内容容量的要求是否相同？
在网上看到两个说法
1.去重对内存容量要求取决于热数据大小
2.去重对内存容量要求取决于磁盘总的 block 大小

[jasonfeng02]

同问，如果总可用容量是 14t ，是只需要按 1g/t 给内存吗，还是按硬盘总容量 14t*2 的大小给 1g/t 内存，我现在是 zfs mirror

[muhairen]

@jasonfeng02 做镜像没有校验信息，raidz 里面还有校验信息，可能不太一样

[wangyuxian95]

我有个 8x16TB 的 z2 pool 开了去重。 我现在很后悔。 本身 dedup pool 是有 900g m.2 做 mirror 。（我 truenas 放在 esxi 里面分配了大概 240GB 的 RAM ）主要用于视频及音乐的文件。 整体 pool 的速度在前 60TB 基本上有 600MB/s 以上峰值可以到 1000 多 但是现在塞满了之后速度只有 500MB/s 并且最要命的是这个速度没法维持。每 10s 钟就会掉到 0 一下。 我个人觉得是去重的问题。

[mrzx]

@wangyuxian95 去重不要开，不然最少内存 double ，建议 x4. 及其消耗内存

@muhairen 磁盘总的 block 大小

zfs 之所以性能有很好的表现，背后都是超多的内存支持着的。。。
低内存想用 zfs,还想性能好?还是打消这个念头吧。。。

[mrzx]

可以参考这篇文章
https://www.a-programmer.top/2021/10/15/ZFS%E7%B3%BB%E5%88%97%EF%BC%88%E4%B9%9D%EF%BC%89%E5%8E%8B%E7%BC%A9%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%8E%BB%E9%87%8D/

数据去重（ Deduplication ，重复数据删除 /重删）
我们还有另一种与压缩相结合的方法来节约磁盘空间，那就是重复数据删除。现在，有三种主要的重复数据删除类型:文件、块和字节。文件重复数据删除是性能最高、系统资源成本最低的。每个文件都使用加密哈希算法进行哈希，比如 SHA-256 。如果哈希值匹配多个文件，则不将新文件存储在磁盘上，而是在元数据中引用原始文件。这可以节省大量空间，但也有一个严重的缺点。如果文件中的单个字节发生了变化，哈希值将不再匹配，这意味着我们不能再在文件系统元数据中引用整个文件。因此，我们必须将磁盘所有块做一个复本，对于大文件，这对性能有很大的影响。

另一种极端情况是字节重复数据删除，这种重复数据删除方法成本最高，因为您必须保留“锚点”，以确定重复数据删除和唯一字节区域的开始和结束位置。毕竟，字节就是字节，是不知道哪些文件需要它们，它只不过是一个数据的海洋。这种重复数据删除技术适用于文件可能被存储多次的存储，即使文件没有在相同的块下对齐，比如邮件附件。

块重复数据删除处于三者中间位置。ZFS 仅支持块重复数据删除。块重删共享文件中所有相同的块。这允许我们只在磁盘上存储唯一的块，并在 RAM 中引用共享块。它比字节重复数据删除更高效，比文件重复数据删除更灵活。然而，它有一个缺点——它需要大量的内存来记录哪些块是共享的，哪些不是。不过，因为文件系统读写数据是以块的方式，所以对现代文件系统使用块重复数据删除是最有意义的。

共享块被存储在所谓的“重复数据删除表”中，文件系统上重复的块越多，这个表就越大。每次写入或读取数据时，重复数据删除表都会被引用。这意味着您希望将整个重复数据删除表保存在快速 RAM 中。如果您没有足够的 RAM ，那么表将溢出到磁盘上。这可能会对存储的性能产生巨大的影响，无论是读数据还是写数据。


数据去重的开销
所以这还有个问题:你需要多少内存来存储你的重复数据删除表?这个问题没有一个简单的答案，但是我们可以对如何处理这个问题有一个很好的总体思路。首先，查看存储池中的块数量。你可以看到这个信息，用如下的命令(耐心点-在它给出报告之前，可能需要一段时间来扫描文件系统中的所有块):

# zdb -b rpool

Traversing all blocks to verify nothing leaked ...

No leaks (block sum matches space maps exactly)

bp count: 288674
bp logical: 34801465856 avg: 120556
bp physical: 30886096384 avg: 106992 compression: 1.13
bp allocated: 31092428800 avg: 107707 compression: 1.12
bp deduped: 0 ref>1: 0 deduplication: 1.00
SPA allocated: 31092244480 used: 13.53%


在本例中，存储池“rpool”中有 288674 块被使用(查看“bp count”)。池中的每个重复数据删除块需要大约 320 字节的内存。因此，对于 288674 块乘以 320 字节 /块，我们得到大约 92 MB 。文件系统大约有 200 GB 大小，所以我们可以假设重复数据删除只能增长到大约 670 MB ，尽管它只有 13.53%被填满。也就是说，每 1GB 的文件系统需要 3.35 MB 的重复数据删除数据，或者每 1TB 的磁盘需要 3.35 GB 的 RAM 。

[mrzx]

最多找个 ssd 开个 log..

还是增加内存 收益最大。。。

自组 NAS ，最好考虑服务器主板，这样会有比较多的内存槽位。ddr4 最大的是单根 32G 一根。还是多考虑下以后扩容内存的事吧。。。。

[mrzx]

UP 主是不是放错区了？这边是宽带症候群,不是 NAS 区

[spediacn]

去重还要看 CPU 性能，有大量的哈希码运算

[muhairen]

@mrzx 宽带症候群和仓鼠症不是相辅相成的么 [滑稽]

[muhairen]

@spediacn 看了 zfs 的去重原理，对于运算的要求不是太高，45w 的四核酷睿足够了

[muhairen]

@mrzx 这里的磁盘总 block 是指可用容量，还是算上冗余了，回到最初的问题，8x16t 用 raidz2 开去重需要 128G 内存还是 96G 内存？

[muhairen]

@mrzx 如果用支持 recc 的服务器板子，ddr4 最大单条就是 64G 了

[mrzx]

@muhairen 128G

在补充一句，跑 zfs 一定要 ecc 或者 recc,为什么，自行谷歌吧

[muhairen]

@mrzx 用 ecc 主要是因为 zfs 主要跑在内存上，这个我知道，其他文件系统倒不一定非得用 ecc ，我一直没搞清楚的是对内存的需要是否计算冗余的部分

[lixile]

@mrzx 有无纯 NVME 存储并使用 truenas 的 配置建议指南或者优化配置的指导