根据Wikipedia所述，ZFS具有以下限制：

• 最高 体积大小：2560000个亿yobibytes（2个¹²⁸字节）
• 最高 档案大小：16 EB（2 ⁶⁴字节）
• 最高 文件数：
  • 每个目录：2 ⁴⁸
  • 每个文件系统：无限制
• 最高 文件名长度：255个ASCII字符（对于多字节字符编码（如Unicode）较少

为什么会有这些限制？是什么在内部限制了这些事情？为什么ZFS在理论上没有无限的卷大小或文件名长度等等？

是什么在内部限制了这些事情？

长答案

ZFS的限制基于固定大小的整数，因为这是在计算机中进行算术运算的最快方法。

替代方法称为任意精度算术，但是它固有地很慢。这就是为什么任意精度算术是大多数编程语言中的一个附加库，而不是默认的算术方式的原因。也有例外，但是这些例外通常是面向数学的DSL，例如bc或Wolfram Language。

如果要进行快速算术，请使用固定大小的单词句点。

在计算机的RAM中，任意精度算术所造成的速度损失已经足够严重，但是当文件系统不知道需要进行多少次读取才能将所需的所有数字加载到RAM中时，这将是非常昂贵的。基于任意大小整数的文件系统必须将多个块中的每个数字拼凑在一起，相对于事先知道其元数据块有多大的文件系统，多个磁盘命中需要大量额外的I / O。

现在让我们讨论一下这些限制的实际含义：

最高 体积大小

2 ¹²⁸个字节实际上已经是无限的。我们可以将这个数字写成大约10 ³⁸字节，这意味着要达到该限制，您必须有一个地球大小的ZFS池，其中10 ^50个原子中的每个原子都用于存储数据，每个字节由不大于10 ^12个原子的元素存储。

10 ^12个原子听起来很像，但是硅只有47皮克左右。

 对于microSD存储，以克为单位的数据密度为2.5×10 ^-13 g /字节，撰写本文时：可用的最大SD卡为1 TB，重量约为0.25g。¹microSD卡并非由纯净的SD卡制成硅，但您不能忽略其包装，因为我们的地球计算机也需要其中的一些包装；我们假设塑料的低密度和金属销的更高密度平均等于硅。我们还需要一些坡度以解决芯片间互连等问题。

甲微微什么是10 ^-12，所以我们的47微克和2.5×10 ^-13  以上克/ B号码相距约一个数量级。这意味着首先要从当前最大可用的microSD卡中构建一个最大大小的ZFS池，您可能必须使用整个地球大小的原子，然后才开始使用接近硅，碳，金等的正确混合的东西，这样您最终不会得到太多的渣，而超出了估算。

如果您认为我在这里使用闪存而不是像磁带或磁盘这样的密集设备不公平，请考虑涉及的数据速率，以及我们甚至没有考虑过冗余或设备更换的事实。我们必须假定，这个地球大小的ZFS池将由不需要替换的vdev组成，并且它们可以足够快地传输数据以使您可以在合理的时间内填充该池。在这里，只有固态存储才有意义。

上面的近似值相当粗糙，存储密度也在不断攀升，但要保持透视：将来，要实现构建最大大小的ZFS池这一绝技，我们仍然需要使用总的壳小行星的核心资源。

最高 文件大小

因此，我们现在有了一个像行星一样大小的文件系统。关于其中存储的文件大小，我们能说什么呢？

让我们为地球上的每个人分配各自大小相等的那个池：

10 ³⁸  ÷10 ¹⁰  ≈10 ²⁸  ÷10 ¹⁹  ≈10 ⁹

那是池的大小除以Earth²的人口除以最大文件大小（以整数表示）。

换句话说，每个人都可以在其地球大小的ZFS存储阵列的微小个人切片中存储大约十亿个最大大小的文件。

（在此示例中，如果让您感到困扰的是，我们的存储阵列仍然只是行星的大小，请记住，它必须这么大才能达到上面的第一个极限，因此可以继续在此示例中使用它这里。）

在ZFS下，每个文件的最大文件大小为16  EiB，比ext4的最大卷大小大16倍，而ext4本身就被认为是可笑的大。

想象一下有人使用他们的Planet ZFS（以前称为Earth）切片来存储最大大小的ext4磁盘映像的备份。此外，这个痴迷的客户（总是一个）决定让tar他们（每个文件16个）达到ZFS最大文件大小限制。这样做之后，该客户仍然有足够的空间再次进行约十亿次操作。

如果您要担心此限制，那是您必须想象要解决的那种问题。而且，这甚至没有获得将文件一次传输到在线备份服务所需的所需数据带宽。

让我们也清楚一下地球计算机的可能性。首先，您必须弄清楚如何构造它，而又不能使其在重力作用下自身塌陷并在中心熔化。然后，您必须弄清楚如何使用地球上的每个原子而没有任何残留炉渣来制造它。

现在，由于您已经将地球计算机的表面变成了地狱，因此所有试图使用该计算机的人们都必须住在其他地方，在这个地方，您经常听到人们在嘲笑计算机的速度。轻微的延迟增加了地球计算机与其现在居住的地方之间的每个事务的延迟。如果您认为今天的〜10ms互联网ping时间是一个问题，可以想象一下，如果我们将地球上的人口转移到月球上，那么在键盘和计算机之间放置2.6毫秒，就可以制造出这台地球计算机了。

ZFS的大小和文件大小限制很大。

最高 每个目录的文件数

2 ⁴⁸大约是每个目录10 ^14个文件，这对于试图将ZFS视为平面文件系统的应用程序来说只是一个问题。

想象一下，一个Internet研究人员正在存储有关Internet上每个IP地址的文件。假设先减去旧的IPv4空间中的松弛空间，然后使用IPv6地址添加主机，以使计算结果准确无误，但现在正好跟踪了2 ^32个 IP。这位研究人员试图解决的是什么问题，这要求他构建一个可以存储2 ¹⁶至65536个以上文件的归档系统！—每个IP文件？

假设这个研究人员也在每个TCP端口存储文件，因此每个IP：端口组合只有一个文件，我们就吃光了2 ¹⁶乘数。

修复很简单：将每个IP文件存储在以IP命名的子目录中，然后将每个端口文件存储在包含每个IP文件的目录的子目录中。现在我们的研究人员可以为每个IP：端口组合存储10 ^14个文件，足以用于长期的全球Internet监视系统。

ZFS的目录大小限制并不是我所称的“科幻小说大片”，正如我们所知，当今的实际应用程序可能会达到此限制，但是层次结构的强大功能意味着，如果您遇到这种情况，您可以仅添加另一个目录层限制。

可能将这个限制设置得很低，这纯粹是为了避免在给定目录中查找文件所需的数据结构太大而无法放入RAM。它鼓励您分层组织数据，从而首先避免此问题。

最高 文件名长度

尽管这个限制确实很严格，但实际上是有道理的。

此限制并非源自ZFS。我相信它可以追溯到4.2BSD中的FFS。我找不到报价，但是当这个限制还很小的时候，有人指出这足够给“给奶奶的一封简短信”。

因此，这就引出了一个问题：为什么您需要用更具描述性的方式命名文件？任何大于此的真正需求都可能需要层次结构，此时您将限制乘以层次结构中的层数再加上一个。也就是说，如果将文件埋入层次结构的3个层次中，则完整路径名称的限制为4×255 = 1020个字符。

最终，此限制是人为限制，而不是技术限制。文件名供人类使用，并且人类实际上不需要超过255个字符即可有效地描述文件的内容。更高的限制根本无济于事。这种限制是古老的（1983年），因为自那时以来，人类一直没有能力应对更长的文件名。

如果您要询问看起来奇怪的“ 255”值从何而来，则基于8位字节的大小有一些限制。2 ⁸是256，这里使用的N-1值可能表示它们使用空终止符在每个文件元数据的256字节字段中标记文件名字符串的结尾。

简短答案

实际上，有什么限制？

脚注：

1. 我使用指定的精度为0.01g的秤进行了测量。

2. 截至本文撰写时为75.5亿美元。上面，我们将这个值四舍五入到10 ¹⁰，我们应该在本世纪中叶达到它。