我希望构建一个更大的 ZFS 池（150TB+），我想听听人们对由于硬件故障导致的数据丢失情况的体验，特别是区分仅丢失部分数据的实例与整个文件系统（如果 ZFS 中甚至有这样的区别）。
例如：假设 vdev 由于外部驱动器外壳断电或控制器卡故障等故障而丢失。从我读过的内容来看，池应该进入故障模式，但是如果 vdev 返回，池应该恢复吗？或不？或者如果 vdev 部分损坏，是否会丢失整个池、一些文件等？
如果 ZIL 设备出现故障会怎样？或者只是几个 ZIL 中的一个？
真正感谢任何和所有由深厚技术知识支持的轶事或假设场景！
谢谢！
更新：
由于我们是一家小型企业（9 人左右），因此我们以低廉的成本进行这项工作，但我们会生成相当数量的成像数据。
数据主要是小文件，据我统计，每 TB 大约有 50 万个文件。
数据很重要，但不是超级关键。我们计划使用 ZFS 池来镜像 48TB“实时”数据阵列（使用了 3 年左右），并将其余存储用于“存档”数据。
该池将使用 NFS 共享。
机架应该在建筑物备用发电机线上，我们有两个 APC UPS 能够在满载情况下为机架供电 5 分钟左右。
设计正确的方式，您将最大限度地减少 ZFS 数据丢失的可能性。不过，您还没有解释您在池中存储的内容。在我的应用程序中，它主要服务于 VMWare VMDK 并通过 iSCSI 导出 zvol。150TB 不是小数目，所以我会向专业人士寻求扩展建议。
我从未使用 ZFS 丢失过数据。
我经历了其他一切：
但通过所有这些，从来没有明显的数据丢失。只是停机时间。对于位于此存储之上的 VMWare VMDK，在发生事件后通常需要执行 fsck 或重新启动，但这并不比任何其他服务器崩溃更糟糕。
至于 ZIL 设备丢失，这取决于设计、您存储的内容以及您的 I/O 和写入模式。我使用的 ZIL 设备相对较小 (4GB-8GB)，功能类似于写缓存。有些人镜像他们的 ZIL 设备。使用高端 STEC SSD 设备使镜像成本过高。我改用单个DDRDrive PCIe 卡。规划电池/UPS 保护并使用带有超级电容器备份的 SSD 或 PCIe 卡（类似于 RAID 控制器BBWC 和 FBWC 实施）。
我的大部分经验都在 Solaris/OpenSolaris 和NexentaStor方面。我知道人们在 FreeBSD 上使用 ZFS，但我不确定 zpool 版本和其他功能落后了多远。对于纯存储部署，我建议采用 Nexentastor 路线（并与经验丰富的合作伙伴交谈），因为它是一个专门构建的操作系统，并且在 Solaris 衍生产品上运行的关键部署比 FreeBSD 多。
我不小心在最新版本的 OpenSolaris 上覆盖了两个 ZIL，导致整个池不可挽回地丢失。（我犯了一个严重的错误！我不明白失去 ZIL 就意味着失去池。幸运的是从备份中恢复了停机时间。）
尽管从版本 151a 开始（不知道 ZPool 版本是什么意思），这个问题已经得到解决。而且，我可以证明它有效。
除此之外，我在 20tb 服务器上丢失了零数据——包括由于用户错误、多次电源故障、磁盘管理不当、配置错误、大量磁盘故障等进一步的情况。即使管理和尽管 Solaris 上的配置界面在不同版本之间频繁且令人抓狂地变化，并且提出了不断变化的重要技能目标，但它仍然是 ZFS 的最佳选择。
我不仅没有丢失 ZFS 上的数据（在我犯下可怕的错误之后），而且它一直在保护我。我不再遇到数据损坏 - 在过去的 20 年里，无论我做什么，在任何数量的服务器和工作站上，这都困扰着我。无声（或只是“非常安静”）的数据损坏让我无数次丧命，当数据从备份循环中滚出时，但实际上已经在磁盘上损坏。或备份备份损坏版本的其他情况。这比一次性大量丢失数据要严重得多，数据几乎总是备份的。出于这个原因，我只是喜欢 ZFS，无法理解为什么校验和和自动修复十年来一直没有成为文件系统的标准功能。（诚然，真正生死攸关的系统通常有其他确保完整性的方法，
明智的话，如果您不想陷入 ACL 地狱，请不要使用 ZFS 内置的 CIFS 服务器。使用桑巴。（虽然你说你使用 NFS。）
对于 ZFS，我不同意 SAS 与 SATA 的争论，至少不同意 SAS 总是优于 SATA 的建议。我不知道该评论 [s] 是否引用了盘片旋转速度、假定的可靠性、接口速度或其他一些属性 [s]。（或者可能只是“它们的成本更高并且通常不被消费者使用，因此它们更优越”。最近发布的行业调查（我敢肯定仍在新闻中）显示，SATA 实际上比 SAS 平均寿命长，至少调查的样本量很大。（这肯定让我震惊。）我不记得那是 SATA 的“企业”版本，还是消费者，或者速度是多少——但根据我丰富的经验，企业和消费者模型同时失败具有统计意义的比率。（尽管存在消费者驱动器在出现故障时超时时间过长的问题，这在企业中绝对是重要的——但这并没有困扰我，我认为这与硬件控制器更相关，它可以占用整个在这种情况下卷离线。但这不是 SAS 与 SATA 的问题，ZFS 从未让我失望。由于这种经验，我现在混合使用 1/3 的企业和 2/3 的消费者 SATA 驱动器.) 此外，如果配置正确（例如，一条三向镜），我发现这种 SATA 组合没有显着的性能影响，但我的 IOPS 需求又很低，所以取决于你的商店有多大和典型用例，YMMV。我确实注意到，在我的用例中，每个磁盘的内置缓存大小对于延迟问题比盘片转速更重要。
换句话说，它是一个包含多个参数的信封：成本、吞吐量、IOPS、数据类型、用户数量、管理带宽和常见用例。说 SAS 始终是正确的解决方案是无视这些因素的大量排列。
但无论哪种方式，ZFS 都绝对令人惊叹。