咨询 NAS 的硬盘组合问题， ZFS、MergerFS+SnapRaid、普通 Raid

1 的 FYI: zfs 的 raidz 在一个多盘 raid 单位 ("vdev") 建好后不能通过加盘来加容量（用正确的方法可以逐块盘替换成大容量）。如果这点不是问题我觉得 zfs 的 raid 挺好的。

@momocraft 嗯，对的，这一点确实也是个缺点，不过最近稍微有些进展，https://github.com/zfsonlinux/zfs/pull/8853，鉴于 3*8T 应该可以组 Raid 后有 14T 的容量，应该够用挺长时间的，这个 feature 到时候应该也差不多能 release，剩下就是不同容量的盘的替换扩容问题了= =

我没组 raid，3 块数据盘，1 快备份盘，重要数据实时同步到备份盘，然后通过自带的网盘软件同步到本地。

> #2

我还不是很相信 zfsonlinux (现在用的裸机 /freebsd), 不过 freebsd 将来要改用 zol 了, 总之也是好消息

@smilzman 我也是这样，还有一块异地备份盘。软 raid 没意思，还不如 basic

@smilzman 如果是这样直接使用 Basic 模式的话，如果是自建，我推荐可以考虑 SnapRaid + MergerFS 的方式，完全没有损失作为 Basic 模式下的那些优点，并且还有一些独有的优点
我想要用 ZFS 主要是还是有一大部分的碎片文件存在，想通过 Raid 的方式提高一些性能，并且能够有一定的可靠性

@sidkang 我目前用的 ZFS FREENAS 的方案。

兄弟，首先要明确你的 nas 想干嘛。
如果想跑日常 dev 可以按 pve 硬盘直通啥的，如果单纯是存储数据可以按 freenas 或 XigmaNAS，两个方向，一个是应用开发向，一个是稳定存储向。
接下来应该是存储文件的冷热分离，日常不经常使用的冷文件可以放到机械硬盘上，日常常用的热文件最好放在 ssd 上。
最后才是考虑数据存储介质的问题，推荐 4 块机械硬盘组一个 zfs，ssd 组一个 zfs。
ssd 定期快照备份到机械硬盘。
机械硬盘不用快照，定期扫描就行。

我的方案仅供参考。
只有一个主板，所以 host 是 pve，直通给 guest4 块 8t 的硬盘，guest 是 XigmaNAS，四块 8t 组成一个 zfs。
剩下的 2 块 ssd 都是笔记本升级淘汰下来的，安装 pve 的时候格式化为 zfs，shell 开了 smb git 做开发机。
之前 pve 里面还跑了个 ros 当主路由，很稳定。
后来家里宽带升级到 400m，破 j1900 板子跑不到上限，直接换了个 hap ac2，pve 里面现在就个小破站了。

1 hdd 用 zfs 比较稳定，之前多次停电都没问题，无 ups

2 普通 raid 和 zfs 性能区别不大，主要区别在于 zfs 支持快照和自压缩及自恢复，普通 raid 停电很容易出问题

3 仓库存储建议使用稳定的 freenas 或 XigmaNAS，开发存储可以直接 pve 接管，我用的方案就是分开了

这个方案优点是稳定，即使 pve 跪了，插一个 XigmaNAS 的 u 盘就可以再次启动 4 块机械硬盘的 zfs，pve 快照定期写入机械硬盘，可以随时恢复。
缺点也有，缺点是运行两个系统 pve 和 XigmaNAS，多耗费一点内存。
直接 pve 管理可以省点内存，XigmaNAS 比较节省内存支持嵌入式，比 freenas 节省，4g 内存就能跑的很好。
pve 直接管理也可以但是数据没有分离开，如果出现灾难恢复是个问题。

以上，希望能帮到你

MergerFS+SnapRaid

ZFS 的 snapshot 和 compression 还是很好用的（

@lulu00147 灰常感谢你的回复，我这台应该会和你的差不多，应用向和存储向都有需求，理解，如果是这样的话，那我就考虑直接在 proxmox 下做三个 zpool，U 盘，SSD，HDD 分别各一个，内存其实问题不大，目前已经上 32G，而且我的存储容量目测不到 15T，这方面应该还好。
不过我注意到你的配置方式里应该是采用直通硬盘的方式到 VM 的方式来组成 HDD 的 ZPool 的，这个在 Freenas 的官网说不太推荐在 vm 下这么做，如果实在要在 vm 下管理，应该把整个 sata controller 直通给 vm 来管理（我目前的方式是 host 装 proxmox，给黑群直通了硬盘来用，感觉不是很放心，所以打算重新搞一遍，机器只有 4 盘位 3.5，所以最多也就 raid5，但是未来肯定会上大容量硬盘，目前看来但盘容量越大，raid5 就越不合适，所以想想就打算趁着升级硬件的机会彻底解决这个问题）
以下是 freenas 的原文：
ZFS combines the roles of RAID controller, Volume Manager, and file system, and since it’s all three in one, it wants direct access to your disks in order to work properly. The closer you can get ZFS to your storage hardware, the happier ZFS is, and the better it can do its job of keeping your data safe. Things like native virtual disks or virtual disks on RAID controllers insulate ZFS from the disks, and therefore should be avoided whenever possible. Using a hypervisor, you typically have a disk on a RAID controller presented to a hypervisor which creates a datastore with a disk on it running FreeNAS. This places two layers between ZFS and the physical disks which warrants taking the following precautions.

Precautions
If you are not using PCI passthrough (more on that below), then you must disable the scrub tasks in ZFS. The hardware can “lie” to ZFS so a scrub can do more damage than good, possibly even permanently destroying your zpool.
The second precaution is to disable any write caching that is happening on the SAN, NAS, or RAID controller itself. A write cache can easily confuse ZFS about what has or has not been written to disk. This confusion can result in catastrophic pool failures.
Using a single disk leaves you vulnerable to pool metadata corruption which could cause the loss of the pool. To avoid this, you need a minimum of three vdevs, either striped or in a RAIDZ configuration. Since ZFS pool metadata is mirrored between three vdevs if they are available, using a minimum of three vdevs to build your pool is safer than a single vdev. Ideally vdevs that have their own redundancy are preferred.

超过 500G 的硬盘用 raid5 也不是不行，反正尽可能勤做备份吧

@sidkang
1.千万不要用黑群做安全存储，血泪史啊，我以前用的黑群，一次家里停电就跪了，只有一次，花了 2000 多找人恢复的数据，费了老大劲了。
2.vm 使用 freenas 直通我没有发言权，我用的是 xigmanas 没啥问题很稳定。
建议问问其他兄弟。

如果喜欢黑群的 app，可以在 pve 按黑裙分个 20g 硬盘，黑群里面挂载 pve 的 smb 共享，类似这种方案，毕竟 zfs 安全太多了。

@lulu00147 嗯，确实是这样，打算文件系统通过 nfs 挂载到黑群晖的方式来使用

没 ECC 内存的话，zfs 其实也没好太多

@sidkang 谢谢哈，看了一下 SnapRAID 数据独立和非实时还不错的，不过现在已经够用了，懒得去折腾=。=

ZFS 的自恢复真的很赞，前段时间把内核搞坏了，重新覆盖安装新的系统，ZFS 自动挂载了，数据一点都没丢。

@SaltyLeo 不错，我已经把 zpool 建好用起来了，找时间再好好研究一下= =

@lucifer9 ECC 的争论好像挺多的，不过目前看下来主流的讲法还是“ECC 其实不是 ZFS 特殊，而是任何系统用 ECC 内存都更推荐”，我买的主板也是支持纯 ECC 的，不过纯 ECC 有点难买，打算以后方便的时候再搞

我用的 gentoo + 用的 zfs 文件系统

@sidkang 我最近也在研究，我是 8sata 位主板，准备放 6 个 sata HDD 12T 的做存储，剩下两个放 SATA 的 SSD，然后一个 M.2，U 盘放 PVE 引导。PVE 虚拟出 Freenas 管理存储，软路由加上其他虚拟机跑一些应用。然后正在考虑应用层是用 iSCSI 内网万兆给白裙实现还是在 PVE 下面直接开个虚拟机跑个其他好用的系统实现。目前存储这看你的意思是直接 sata controller 给 freenas 比较好，而不是直通每块硬盘？那 SSD 也是吗？两块 SSD 可以作为 freenas 的缓存吧？然后 M.2 跑应用？这样是不是好点

@raphael 我目前是直接由 pve 管理所有的硬盘，2U 盘做启动盘，2SSD 组一个 pool，4HDD 组一个 raidZ1pool ；如果是用 freenas 的话，确实建议直接直通控制器，这样 freenas 才可以读取到磁盘实际信息，这样的话 SSD 自然也就转给 freenas 了，ssd 可以做缓存，M.2 的意义不会特别的大，其实 SATASSD 已经足够快了。如果是为了用 zfs 的话，我建议就直接 pve 管理好了，管理也方便，不用特意拿 freenas vm 来管理。
另外，ssd 作为 zfs 缓存的话，建议仔细读读文档和资料，需要琢磨一下，不然可能反而会降低性能

@sidkang 好的，pve 管理硬盘的话，即使用 ZFS，是不是 freenas 的一些高级功能就用不了了？ M.2 的 SSD 主要是想跑一些其他虚拟机的时候加快速度，还有就是万兆的话可能用得到

@raphael 如果想扩容的时候省点钱，可以考虑一下让 zfs 跑在 lvm 上，每个硬盘弄一个 thin lv，然后通过 zfs 组成 raidz，记得给 lvm.conf 中配置 thin_check_options = [ "-q", "--clear-needs-check-flag", "--skip-mappings" ] ，否则开机检查要好久。因为 zol 0.8.1 增加了 trim，所以开启 zpool set autotrim=on data 后删除文件就会 trim，利用这个可以在需要扩容时删除所有快照，再新建 thin lv 和新的 raidz，再将文件用 rsync 移动过去。

用这种方法可以一次加一块容量相同的硬盘，缺点是必须删除快照。

@lucifer9 #21
任何文件系统没了 ECC 都不安全。
内存有错的情况下，文件数据的损坏仅仅是时间+概率的问题——早晚的事。
至于选择 ZFS 的原因：性能、快照、压缩、冗余、自维护性……这些就够了，本来也没指望非 ECC 的内存能实现什么额外的数据纠错。

@ungrown 大部分文件系统并没有像 ZFS 一样对内存有大量读取写入，对 ECC 的依赖当然不一样。假设内存反转的概率是一定的，那写入 1T 和 50G 出错的概率能一样吗？

@justaname #32
所有强调 zfs 必须或者最好用 ecc 的论调，都是以讹传讹，该观点的始作俑者和一众信徒（不加引号）们都在这个问题上犯了“半桶水想太多但又想得不够多”的错误，其中相当一部分人很难说他们不是借这个观点来进行误导、威吓、党同伐异、赛博宗教迫害。
反驳这一论调的经典文章： https://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data
结论：ecc 有用，但是没必要。没有 ecc 的场景下，zfs 并不会比别的文件系统造成更多损失，相反，zfs 还会避免、修复更多损失，因为其他文件系统没这个能力，是的，这个能力本来也跟内存是不是 ecc 没有关系。如果你感到困惑，上面那条链接可以给你解惑。

以后记得看到某种观点之后，搜搜它的反面，反面不一定是对的，但是兼听则明偏信则暗。

@ungrown 这篇文章我看过，Google 搜索 ZFS non ECC 第三个就是，而另外几个则是反对这个观点的。另外几乎所有支持 ZFS 的平台在 ZFS 的要求都会额外注明 ECC 内存的重要性并强烈建议部署 ZFS 的主机使用 ECC 内存，比如 TrueNAS ，Proxmox ，其中 Proxmox 支持 LVM ，ZFS ，BTRFS 等多种块存储方式，但只有 ZFS 是额外标注仅建议在使用 ECC 内存的情况下部署，同时 ZFS 也是唯一官方强烈建议采用 ECC 内存的文件系统。我不知道 ZFS 官方，Proxmox 官方，TrueNAS 是不是都属于你说的半桶水想太多和宗教迫害。
最后你依然没有回答我一个很浅显的疑问，在内存都可能出错的情况下，对内存重度依赖同时有大量内存读写操作的 ZFS 能在可靠性上跟别的不吃内存的传统文件系统一致吗？既然都有可能出错，0.01%的出错率和 1%的出错率没有差别这种论证显然并不令人满意

@justaname #34 假传圣旨的卑鄙小人！
PVE 官方资料里在 zfs 页面提到了 ecc ，只提到一次，上下文用的词语是 recommend ，除此之外没有哪怕一个地方提及非 ecc 的危害也没有反对使用 ecc 。这叫“强烈”建议？这强烈是你自己加的吧喂！
oracle zfs 、openzfs 、truenas 官方资料中则干脆连 ecc 这个词都搜不到了，唯一把 ecc 奉为圭臬当山歌唱的就是 truenas 论坛里面，你是不是被他们托梦看的“资料”啊？

来，时间充裕，我不跟你玩什么简明扼要的论证，我就是要朝你这种焦虑贩子输出情绪和贬斥。
如果我给的那篇文章链接你真的仔细看了，那下面这段内容你应该已经读过，但是谁知道呢，说不定你嘴上说你读过，其实你可能一个字没看，或者边看边忘呢。

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

这是 2014 年 Matthew Ahrens 在论坛上的回帖 https://arstechnica.com/civis/threads/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux.1235679/page-4#post-26303271
Matthew Ahrens 何许人也？乃 sun 公司当初创造 zfs 的核心人员之一，现今的 Delphix 公司 zfs 开发团队的领导。
他上面说的这段哈啥意思呢？开头他说：zfs 没有什么特别的地方，使它比其他文件系统更加需要、更加依赖 ecc 内存。结尾他说：你实在担心你那宝贝数据出问题，不管是利益休戚相关还是心理作用，你担心，你就上 ecc ，不管你用的啥文件系统，你担心就该上 ecc ，那如果有了 ecc 还嫌不够呢，你还可以加一个 zfs 作为额外的保险。那么是 ecc 的存在才使得 zfs 能够可靠运作吗，不是；是 ecc 让 zfs 变得更好了吗，不是；是什么呢，是 zfs 使 ecc 变得更好了，原因无他，zfs 牛逼，zfs 屌大，zfs 无论在任何内存哪怕是坏内存上都能通过自己的系统将错误减到最小，杀爆在座各位的其他文件系统。
因为 zfs 本身相当于加了一层校验，校验不通过它是不会往盘上回写覆盖数据的。在 zfs 面前，其他的文件系统就是小瘪三。
你有 ecc ，恭喜，你还用了 zfs ，好，双倍校验，双倍恭喜。
你没 ecc ，但你的内存没坏，没事放心用，哦你用 zfs 啊，那更没事了。
你没 ecc ，而且你的内存已经有问题了，跑 memtest 报错那种，呵呵，祝你好运……等下，你用的是 zfs 啊，诶，问题不大，但是还是赶紧换根条子吧，又不贵，非要拼人品赌运气吗？
你没 ecc ，而且内存有问题，而且文件系统还不是 zfs ，emmm ，回去过得开心点吧，想吃啥想玩啥的尽量满足吧，不会太久了。
就你那心心念念的 1%还是 0.01%，你还在乎那几个小数点呢？内存条要是真有这么大的错误率，早蓝屏、内核崩溃了，这么高的错误率，跑 memtest 还不得第一轮就列表格？
但是不用担心，如果你真的有一条这样的内存条，zfs 依然会尽全力避免数据损坏，毕竟除非智子干扰，否则内存里面不会错得那么“巧”，zfs 的块校验就能发现错误，发现了错误就好办了，别往回写不就行了么，你以为 zfs 是跟你一样的脑残呢？
再说，这么宝贝的数据，vdev 肯定有冗余吧，哪有正经人玩存储不戴头盔，啊不是，不设冗余的？
那是我了，我就是这种不正经的人，单硬盘 zpool ，无冗余，无 ecc ，这都快 8 年过去了，要不我再维持现状多跑几年，说不定到时候我哭了，你可以来笑我？

就你这种桶底湿，还学别人半桶水那样晃呢？人家半桶水虽然傻逼但他能晃出响来，你呢？

@ungrown 你翻来覆去说的这些东西只是在论证 1%和 0.01%没差别，然而实际上对大部分“普通用户”来说，这就是“有区别”。事实上你，以及你引用的那篇“经典论文”，依然没有回答我一个最开始的提问，在内存错误率一定的情况下，一个重度依赖 RAM 的文件系统是怎么做到跟不重度读写 RAM 的文件系统一个出错率的。PVE 在且仅在 ZFS 的页面提到过这个“recommendation”，意思是只有使用 ZFS 的用户才会在意数据安全？

你一个单盘 zpool 我都不知道这个经历有什么好特意炫耀的，无冗余说明根本不是重要数据，bit rot 也根本无所谓。我在一块 memtest 有问题，经常蓝屏的 Windows 上运行了几个月 NTFS 上的 RAID 没有任何（我发现的）数据损坏，是不是说明 NTFS 是最好的文件系统？

Matthew Ahrens 何许人也？乃 sun 公司当初创造 zfs 的核心人员之一，现今的 Delphix 公司 zfs 开发团队的领导。我不知道你引用一个 ZFS 利益相关的核心人员做了一通哲学论述是想说明什么？

另外不用回复了，讨论一个文件系统的利弊也能冒出来这么激情四射的宗教式攻击，然后到处旁征博引就是没有实际针对问题的回答。

@justaname #36 fnmdp 1%和 0.01%没差别！
我说的是没差别吗，我说的是这点差别没有意义。
往小了说，1%和 0.01%这种错误率都属于很大的错误率了，这种内存条不换掉属于害人害己。
往大了说，zfs 自带的错误校验和防损机制是不依赖 ecc 的，用普通内存，zfs 依然能发挥它的错误校验功能，内存中的错误不会被回写到介质上。

你又要用 zfs ，又嫌 zfs 核心开发人员提供的结论是利益相关的，你就想听社区里面人云亦云以讹传讹三人成虎贩卖恐慌的 ecc 神教是吧？
是你们把自己臆想出来的东西奉为宝典，软硬兼施，规劝、胁迫别人跟你们一样搞，而且看到质疑和反对的声音就攻击，你们这才是血统纯正的宗教迫害，怎么还有脸来倒打一耙！？

ntfs 本来就是很好的文件系统，要不然为什么这么多人在用？
然而你这个例子恰恰证明了 ecc 本来就不是特别重要，哪怕是 ntfs 这种没有校验功能的文件系统。
zfs 这种校验功能完善的文件系统就更不怕内存翻转了，zfs 不会把内存中错误的块当成正确的提供给用户读取，zfs 不会把内存中错误的块回写到介质上，但是 ntfs 会。
zfs+普通内存 ≈ 其他文件系统+ecc 内存 = 单一校验。
zfs+ecc 内存 = 双倍校验。

你们但凡稍微了解过 zfs 的块校验和错误管理，都不会被一个内存翻转吓到半死。

@ungrown https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html

Hardware Requirements

- ECC memory. This isn’t really a requirement, but it’s highly recommended.

Do I have to use ECC memory for ZFS?

- Using ECC memory for OpenZFS is strongly recommended for enterprise environments where the strongest data integrity guarantees are required. Without ECC memory rare random bit flips caused by cosmic rays or by faulty memory can go undetected. If this were to occur OpenZFS (or any other filesystem) will write the damaged data to disk and be unable to automatically detect the corruption.

- Unfortunately, ECC memory is not always supported by consumer grade hardware. And even when it is, ECC memory will be more expensive. For home users the additional safety brought by ECC memory might not justify the cost. It’s up to you to determine what level of protection your data requires.

麻烦不要激动，你说的和我印象也不太一样，我就随便找了下你说的“oracle zfs 、openzfs 、truenas 官方资料中则干脆连 ecc 这个词都搜不到了，唯一把 ecc 奉为圭臬当山歌唱的就是 truenas 论坛里面，你是不是被他们托梦看的“资料”啊？”中的 openzfs 的资料，ecc 依旧还是很醒目。

总之就是 highly recommended but not required 。

@sidkang #38
是呀，不必要啊
知道啥是必要的吗，跑 memtest 不出错的内存

@sidkang #38 我直接帮你把重点画出来吧，省得还等你下条回复

is strongly recommended for "enterprise environments"
where the "strongest data integrity guarantees" are required

@ungrown 不需要你指出，只是你可以写字不要搞情绪输出就行，挑个明显的错误指出来，不过看你故意无视的样子，显然你觉得无所谓，那还请勿回。

另外我已经上了 ECC 内存，虽然我的存储系统的主力目前没有在用 ZFS 。

@sidkang #41 是呢，来找我对话的是你，说勿回的还是你，对别人这样颐指气使，想必是一个友善的人呢

@sidkang #41 你们自己吓唬自己、浪费资源给自己找心理安慰那是你们的自由，别把别人误导得不懂如何取舍、如何按需配置

@sidkang #41 “挑个错”
指看都没看就把文档内容贴上来，结果发现官方文档里明明白白写了普通用户使用场景那点 B 需求压根没摸到需要考虑 ecc 的门槛，反倒显得自己的“决断”是多么小丑

我服了，劝诫其他看帖用户，千万别招惹中了路边的 XX