Dan*_*ght 6 storage nas freenas zfs
我正在考虑使用 FreeNAS；并想事先确认我对我可以/不能对其中的存储做什么的理解是正确的。
初始构建：1 个存储池，2 个 6TB 驱动器相互镜像；总有效容量为 6TB（忽略舍入和开销）。
第一次扩展（2.5 - 3 年后）：向服务器添加 2 个 12TB 驱动器。将它们配置为第二个镜像对，并将它们添加到现有存储池中；将我的可用存储空间增加到 18TB。
第二个扩展阶段 1（5.5 - 7.5 年）：向服务器添加 2 个 24TB 驱动器。将它们配置为镜像对，并将它们添加到现有的存储池中；将我的可用存储空间增加到 42TB。
第二个扩展阶段 2（紧接在阶段 1 之后）：重新平衡 6TB 驱动器的所有数据，将它们从池中移除，然后从服务器中物理移除。剩余可用存储空间 36TB。
我的想法是：
每隔不到 3 年所需的存储容量就翻一番，这是我从 2008 年到现在使用 WHS 服务器的经验的延续。
添加 24 TB 驱动器后，6 TB 驱动器仅提供总存储量的一小部分（1/7）并且已经足够老，如果我将它们保留在（浴缸曲线的错误一侧），可靠性将成为更重要的问题. 如果他们幸存下来，按照我的增长速度，我需要购买 48TB 驱动器的时间只会延长半年多一点；所以他们真的不会给我太多时间。
将自己限制为 4 个驱动器让我可以为我的 nas 使用紧凑的 mini-ITX 外形。超过这意味着更大和更昂贵的设置。（将 2 个驱动器放在开放式机箱的顶部，并且电线蜿蜒而出，在一两天的过渡时间内是可以接受的；但不能长期使用。）
我还假设大驱动器的可用性照常营业，就像我之前大约 3 年的升级一样：1.5-3tb（2012 年）和 3-6TB（现在/不久的将来）。并且无论新驱动器是否可用，都将足够可靠以供使用（即突袭末日永远不会发生）。
use*_*ser 16
首先：我不会推测未来 6-7 年的发展。这是关于今天和最近的未来。对于TL;DR，请参阅此答案的底部。
今天的 ZFS 不允许您从池中删除 vdev。它也没有任何原生的“重新平衡”功能（搜索block-pointer rewrite、bp rewrite或bpo rewrite以了解更多信息）。ZFS确实允许您降低镜像的冗余级别，但不是 raidzN、vdev，但这不是您想要的。（在 ZFS 中，条带化是您什么都不说时所得到的。）
基本上，池可以被认为是由一个或多个存储设备组成的条带集，只有后者 (vdevs) 可以安排在冗余配置中。您可以将每个 vdev 配置为任意高级别的冗余，但池中的每个vdev 都必须保持在其冗余阈值之上，才能使池充分发挥作用。如果一个虚拟设备出现故障，充其量你只会丢失了存储在该虚拟设备中的数据，并没有办法主动控制数据都存储其上vdevs（不是把他们单独的池，其中有其他缺点等）。
当您拥有一个“镜像”池（例如您在第一次扩展后描述的那个池）时，您真正拥有的是两个 vdev，每个都由一对镜像的物理存储设备组成，其中两个 vdev 被条带化以形成池。即使另一个镜像集工作正常，两个 vdev 两个驱动器每个镜像池可能会因一个故障驱动器和该镜像集中另一个驱动器上的一个不幸错误而关闭。在这种失败的情况下，无论发生什么，都会丢失一些数据。
在 ZFS 池中提高容量的正常方法是用更大的驱动器替换就地驱动器，允许池重新同步到新驱动器，然后物理移除不再使用的旧驱动器。通常，人们希望在zpool replace连接旧驱动器和新驱动器的情况下使用此功能，以在整个过程中保持所需的冗余级别。正常的替代方法是添加与池中现有 vdev 具有相同冗余级别的 vdev。再次请注意，由于 ZFS 不支持删除条带集的一部分，并且池严格由条带化 vdev 组成，因此一旦添加了 vdev，就无法将其删除。很多 ZFS 新手都落入了这个陷阱，如果您不注意所使用的确切命令，很容易搞砸。
由于 ZFS 重新同步器的工作方式，重新同步对于所涉及的驱动器来说是极其痛苦的。传统的 RAID 重新同步器通常大多是连续的，少量随机 I/O 散布在用户活动中，而 ZFS 重新同步器几乎是完全随机的 I/O，其中散布着来自用户活动的随机 I/O。一套镜子在其整个生命周期中看到的活动大致相同；如果一个驱动器处于边缘状态，甚至已经死亡，则另一个驱动器很可能也处于边缘状态。让它连续几天经受重新恢复的折磨可能很容易将它推到边缘。（根据个人经验，我猜想，要重新同步 6 TB 数据，您需要进行大约一周的重新同步过程。即使您转动所有旋钮调至 11，基于纯粹的顺序吞吐量——考虑到 ZFS 的磁盘格式和重新同步策略，这是完全不现实的——你正在寻找至少大约 17 小时的驱动器绝对恐怖。我最好的猜测是，没有办法将 6 TB 的 resilver 降低到不到完全驱动滥用的两倍，或者一天半的时间。）
我也会对 2x24TB 甚至 2x12TB 镜像配置产生非常严重的怀疑，假设这样的驱动器实现了；我们已经在用当前的驱动器大小推动物理的边界（没有双关语）。假设驱动器的可靠性，就URE 而言，仍然与今天相似（每次读取 10^-14 到 10^-15 个扇区错误，这是它在制造商数据表中永远徘徊的地方），从统计上讲，你不会能够完整读取 12TB 驱动器而不会遇到至少一个错误（12 TB 大约为 9×10^13 位，四舍五入为 10^14）。当您将其推送到 24 TB 驱动器时，从统计上讲，您至少会遇到一次完整读取过程中出现一两个完整扇区错误（因为您正在读取大约 2*10^14 位）。即使您使用 10^-15 个 URE 驱动器，也不会给您带来太多好处（然后您会看到 5 次读取通过，而不是半次读取通过）。当然，这是统计数据和规范；在实践中，读取错误倾向于聚集在一起，并且驱动器可能会为许多完整读取提供无故障服务，然后在某个时刻开始向左和中心抛出错误。
鉴于大多数非服务器微调器的保修期仅为 1-3 年，我不会指望任何设备的工作时间比这更长，而您的计划要求它们在被取代之前保持功能至少六年. 即使是服务器微调器通常也只有五年的保修期，尽管通常是 5 年 24x7 的运行。我个人的经验是，高端消费级硬盘，比如希捷的Constellation ES系列，在放弃鬼魂进入数据天堂之前，可以提供几乎这个级别的职责。（个人轶事：一个 1 TB 的 Constellation ES.2，当它开始表现出有趣的时候，我已经有 4 年 9-10 个月的时间了，尽管我从来没有失败过。）
一般而言，考虑到许多运行 ZFS 的人会在微调器大小达到 3-4 TB 或更小以获取更重要的数据时采用双冗余。这样做是有充分理由的：存储设备出现故障并且发生频率惊人。在 ZFS 的情况下，如果您想要的不仅仅是返还碰巧仍然可以从盘片中读取的原始位，那么您还会考虑更昂贵的数据恢复服务，而且我不知道有任何数据恢复软件可以甚至可以远程处理 ZFS 池。如果 ZFS 无法导入您的池，最实用的答案通常是将您未在其他地方备份的任何数据视为丢失。
FreeNAS/ZFS 会让我以这种方式管理我的存储吗
从严格的技术意义上讲，是的，它应该。但是，我真的不推荐它。你把硬件的操作范围推得太远了，我对它感到不舒服，更不用说认可它了。（请注意，无论您询问的是哪种文件系统，此答案几乎完全相同。）