我一直在使用FreeBSD 8.0和随后的8.0-stable-February 2010快照来试用ZFS几个月。该系统具有几个独立的4盘RAIDZ1池。起初，事情似乎或多或少完美，尽管我遇到了一些越来越令人不安的问题，这使我认为在某些特定的情况和配置下，避免这种设置可能是明智的。我的第一个问题不一定是FreeBSD / ZFS本身的稳定性/功能，而是FreeBSD下某些设备驱动程序和光盘驱动器的可靠性和功能。我发现默认的ata / ide驱动程序不支持我使用的控制器，但是siis硅映像存储驱动程序具有所需的端口倍增器SATA支持，以使驱动器可与FreeBSD 8一起使用。但是，在仔细检查后发现驱动程序代码还没有真正投入生产，恕我直言-它没有很好地处理与磁盘相关的第一个软错误/超时/重试条件，该条件导致阵列中的驱动器执行延迟响应等数十次操作秒。我不知道到底发生了什么，但是阵列花了大约一分钟时间才超时，重置和重新建立操作，在此期间，阵列中的每个驱动器都从操作状态“丢失”，并导致不可恢复的数据故障在更高的文件系统级别。AFAICT甚至SIIS驱动程序的维护者都说，驱动程序的超时/重置处理尚未真正完全完成/稳定/优化。足够公平，但是重点是，无论OS或ZFS多么出色，如果您的磁盘驱动器，控制器或驱动器不可靠，那么尽管使用ZFS，它肯定会破坏整个操作，足以导致致命的错误和数据丢失。同样，SMART诊断请求似乎不适用于此特定的控制器驱动程序。至于是什么引起了错误..片状希捷驱动器/固件？我不知道，但是尽管RAIDZ破坏了RAIDZ的可靠性，但发生一个驱动器错误会导致整个阵列“故障”。zpool scrup问题的后续行为/ zpool status等。等 还是有点可疑，目前还不清楚该诊断/恢复过程是否在ZFS / ZPOOL级别正常工作；当然，我收到一些有关错误状态和错误清除等的混合消息。等 尽管缺少显式的zpool clear命令，但重新启动后错误指示仍然消失；也许这是有意的，但如果是，则zpool status输出不建议这样做。
可能更严重的是，经过几天的正常运行时间后，操作期间似乎出现了一些静默错误，其中包含多个文件系统（ZFS）的阵列的大部分刚从“ ls”中列出并从正常的I / O访问中消失了。IIRC df -h，ls等即使存在，也没有报告文件系统，而zpool list / zpool status继续指示池中预期消耗的存储量，但是任何列出的已挂载或卸载的文件系统。/ var / log / messages不包含任何错误情况消息，并且在此问题之前，操作完全按照正常进行。zpool list / zpool status并不表示池有问题。zfs卸载-a失败，并没有繁忙的指示，这与在最后一个挂载的zfs文件系统卸载之前几分钟的交互使用没有明显关系。重新引导并重新检查/ var / log / messages，zpool状态，zpool列表并不能说明任何问题。实际上，以前丢失的文件系统实际上是在被要求手动重新安装时才重新安装的，并且最初看起来具有正确的内容，但是在一分钟左右的时间里，将各种zfs系统安装到池中后，注意到某些文件系统再次意外地消失了。我可能
当然，我正在运行不推荐用于生产的Feb'10稳定快照，但是自8.0发行版以来，已经对稳定分支提交了一些相对值得注意的已知ZFS /存储问题的修复程序，因此，运行库存8.0可能是由于某些问题，在可靠性/功能方面不能令人满意。
无论如何，仅仅几周的相当轻松的测试就已经导致了足够的潜在灾难性可靠性/功能性问题，似乎并非所有这些都与我对信任FBSD 8.0持谨慎态度的存储驱动器/控制器/驱动器的特定缺陷有关。 + ZFS用于生产/可靠性，无需非常仔细地控制硬件和软件配置以及脱机备份策略。
即使您要运行它，OpenSolaris还是现在无法使用，恕我直言-显然，zfs重复数据删除存在严重的已知问题，几乎使其无法使用，并且该问题和其他问题似乎已建议您等待在信任OpenSolaris + ZFS之前，还会发布其他一些补丁版本，尤其是对于dedup系统。B135 / B136似乎只是缺少发布而没有解释，以及2010.03主要操作系统版本。有人说甲骨文对计划表的延误只是tight之以鼻，但是预期的代码最终会迟来发布，而另一些人则怀疑我们是否会看到Sun开发的全套预期功能会作为将来的开源版本发布？由甲骨文赋予了所有权/领导权/管理权的过渡。
恕我直言，我只坚持使用镜像，并且只采用经过严格审查/稳定的存储控制器驱动程序和磁盘驱动器模型，以在FreeBSD 8下获得最佳的ZFS可靠性，即使这样我也可能要等待8.1。