目前的配置如下 i5-8500 2*DDR4-16G 2*32G SLC-U 盘 2*500G-860evo 1*250G-SSD 3*8T-HDD
目前机箱可以容纳 4*3.5，2*3.5，剩余如果加 SSD 的话可以通过双面胶大法解决，主板上有 8SATA 口，1M.2，1PCI-Ex16，目前仅使用了 6SATA 口
未来会逐步提升配置，SSD 应该会根据需要慢慢加，3.5HDD 最多也只能加一个盘了，然后就只能替换更大容量的

目前初步的软件配置，Host 通过双 SLCU 盘组 Raid1/RaidZ-mirror 安装 Proxmox ； 2 个 SSD 组 raid1 或 RaidZ-mirror，主要用于放 vm 以及从系统盘移出来可能需要频繁读写的 Cache 和日志目录； 3 个 HDD 组 RaidZ/(MergerFS+SnapRaid)/普通 Raid，需要存储的资料主要是一些媒体资料，这些改动不会太频繁，还有一些是工作用材料，这一部分主要是零碎文件，但是数量很多，也会经常做变动

目前有些犹豫不确定的有这么几个点：
1、HDD 方面，因为还是有一些变动多一些的文件，所以倾向于用 ZFS 或者 Raid 的方式，Snapraid+MergerFS 的特性使得无法及时对写入的数据进行保护（不太适用于频繁改动的文件）；
2、SSD 方面，因为容量比较小，所以即便使用 ZFS 升级也还算方便，直接把数据拷贝出来即可，我的疑问是想说，对于 SSD 来说，组普通 Raid 和 ZFS 的性能方面差距有多大呢？，主要想提升 4k 随机方面的性能，如果差不多的情况下我可能倾向于使用普通 Raid
3、针对于组合 Raid，大家是推荐直接在 Proxmox 上设置并管理 ZFS 及磁盘空间，还是推荐通过 VM 直通 SATA controller 的方式来管理好呢？
提前感谢各位，这些问题实在疑问了很久
1 的 FYI: zfs 的 raidz 在一个多盘 raid 单位 ("vdev") 建好后不能通过加盘来加容量（用正确的方法可以逐块盘替换成大容量）。如果这点不是问题我觉得 zfs 的 raid 挺好的。

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

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

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

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

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

我目前用的 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 还是很好用的（

灰常感谢你的回复，我这台应该会和你的差不多，应用向和存储向都有需求，理解，如果是这样的话，那我就考虑直接在 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 也不是不行，反正尽可能勤做备份吧


1.千万不要用黑群做安全存储，血泪史啊，我以前用的黑群，一次家里停电就跪了，只有一次，花了 2000 多找人恢复的数据，费了老大劲了。
2.vm 使用 freenas 直通我没有发言权，我用的是 xigmanas 没啥问题很稳定。
建议问问其他兄弟。
如果喜欢黑群的 app，可以在 pve 按黑裙分个 20g 硬盘，黑群里面挂载 pve 的 smb 共享，类似这种方案，毕竟 zfs 安全太多了。

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

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

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

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

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

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

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

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

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

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

如果想扩容的时候省点钱，可以考虑一下让 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 移动过去。
用这种方法可以一次加一块容量相同的硬盘，缺点是必须删除快照。


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