答案1
是什么在内部限制了这些东西？
长答案
ZFS 的限制基于固定大小的整数，因为这是在计算机中进行算术运算的最快方法。
另一种方法称为任意精度算术， 但它本质上很慢。这就是为什么任意精度算术是大多数编程语言中的附加库，而不是默认的算术方式。也有例外，但这些通常是数学导向的DSL喜欢bc或者Wolfram 语言。
如果你想要快速算术，你可以使用固定大小的单词，句号。
在计算机的 RAM 中，任意精度算术对速度的影响已经够糟糕的了，但是当文件系统不知道需要进行多少次读取才能将所需的所有数字加载到 RAM 中时，那就是非常昂贵。基于任意大小整数的文件系统必须将多个块中的每个数字拼凑在一起，相对于预先知道其元数据块有多大的文件系统，需要来自多个磁盘命中的大量额外 I/O。
现在让我们讨论每个限制的实际重要性：
最大限度。体积大小
2 128字节实际上已经是无限的了。我们可以将该数字写为大约 10 38字节，这意味着为了达到该限制，您必须拥有一个地球大小的 ZFS 池，其中每个10 50 个原子用于存储数据，每个字节由不大于10 12个原子的元素存储。
10 12 个原子听起来很多，但它是仅约 47 皮克硅。
截至撰写本文时，microSD 存储的数据密度（以克为单位）为 2.5×10 -13 g/字节：最大的可用 SD 卡为 1 TB，重量约为 0.25g。硅，但你不能忽视包装，因为我们的地球计算机也需要一些硅；我们假设塑料的低密度和金属销的较高密度平均起来与硅的密度大致相同。我们还需要一些斜率来解释芯片间互连等。
一个微微-任何事物是 10 -12，所以我们上面的 47 pg 和 2.5×10 -13 g/B 数字大约相差一个数量级。这意味着，首先，要使用当前最大的可用 microSD 卡构建单个最大尺寸的 ZFS 池，您可能必须使用整个地球大小的行星的原子，并且只有当您开始时接近硅、碳、金等的正确组合的东西，这样你就不会得到太多矿渣你超出了估计。
如果您认为我在这里使用闪存存储而不是磁带或磁盘等更密集的存储设备是不公平的，请考虑所涉及的数据速率，以及我们甚至没有尝试考虑冗余或设备更换的事实。我们必须假设这个地球大小的 ZFS 池将由虚拟开发者永远不需要更换，并且它们可以足够快地传输数据，以便您可以在合理的时间内填满池。在这里只有固态存储才有意义。
上面的近似值相当粗略，并且存储密度继续攀升，但请正确看待：将来，为了完成构建最大尺寸 ZFS 池的特技，我们仍然需要使用总的地壳到 -的核心资源小行星。
最大限度。文件大小
所以我们有一个行星大小的文件系统现在。关于其中存储的文件的大小我们能说什么呢？
让我们为地球上的每个人提供同样大小的池子：
10 38 ÷ 10 10 ≈ 10 28 ÷ 10 19 ≈ 10 9
这是池的大小除以地球人口²除以最大文件大小（以整数表示）。
换句话说，每个人都可以在我们地球大小的 ZFS 存储阵列的个人小切片中存储大约 10 亿个最大大小的文件。
（如果您对本例中我们的存储阵列仍然是行星大小感到困扰，请记住它必须那么大才能达到上面的第一个限制，因此在本例中继续使用它是公平的这里。）
每个文件的最大文件大小为 16 欧洲银行在 ZFS 下，即比 ext4 最大卷大小大 16 倍，今天它本身就被认为是大得离谱。
想象一下有人使用他们的 Planet ZFS（以前称为 Earth）切片来存储最大大小的 ext4 磁盘映像的备份。此外，这位疯狂的顾客（总有一个）决定tar它们最多，每个文件 16 个，只是为了达到 ZFS 最大文件大小限制。完成此操作后，该客户仍然有空间这样做再次大约十亿次。
如果您要担心这个限制，那么您必须想象需要解决这种问题。这甚至没有考虑将该文件传输到在线备份服务所需的数据带宽一次。
我们还要弄清楚地球计算机的可能性有多大。首先，你必须弄清楚如何建造它，而不让它在重力作用下自行塌陷并在中心熔化。然后你必须弄清楚如何使用地球上的每一个原子来制造它，而不需要任何剩余的炉渣。
现在，既然你已经把地球计算机的表面变成了地狱，所有试图使用该计算机的人都必须住在其他地方，一个你经常听到人们咒骂速度的地方——轻微的延迟会增加地球计算机与他们现在居住的任何地方之间的每笔交易的延迟。如果您认为今天大约 10 毫秒的互联网 ping 时间是个问题，想象一下2.6光秒如果我们将地球人口移至月球，那么我们就可以制造出这台地球计算机。
ZFS 的体积和文件大小限制是科幻小说中的巨大限制。
最大限度。每个目录的文件数
2 48大约是每个目录 10 14 个文件，这对于尝试将 ZFS 视为一个文件系统的应用程序来说只会是一个问题。平面文件系统。
想象一下，一位互联网研究人员正在存储有关互联网上每个 IP 地址的文件。假设首先减去旧 IPv4 空间中的闲置空间，然后添加现在使用 IPv6 地址的主机以使算术结果良好，之后正好有 2 32 个IP 被跟踪。这位研究员想要解决什么问题，需要他构建一个可以存储超过 2 16 — 65536 的文件系统！ — 每个 IP 的文件？
假设该研究人员还为每个 TCP 端口存储文件，因此每个 IP:端口组合仅存储一个文件，我们就耗尽了 2 16乘数。
修复方法很简单：将每个 IP 文件存储在以 IP 命名的子目录中，并将每个端口文件存储在保存每个 IP 文件的目录的子目录中。现在，我们的研究人员可以为每个 IP:端口组合存储 10 14 个文件，足以用于长期的全球互联网监控系统。
ZFS 的目录大小限制并不是我所说的“科幻小说中的大限制”，正如我们所知，当今的实际应用程序可能会达到此限制，但层次结构的强大功能意味着，如果遇到以下情况，您可以添加另一个目录层：限制。
这个限制可能设置得这么低，纯粹是为了避免在给定目录中查找文件所需的数据结构太大而无法放入 RAM。它鼓励您分层组织数据，以避免出现此问题。
最大限度。文件名长度
虽然这一限制看起来确实很严格，但实际上是有道理的。
此限制并非源自 ZFS。我相信它可以追溯到4.2BSD 中的 FFS。我找不到引用的内容，但是当这个限制还很小时，有人指出这个空间足够写“给奶奶的一封短信”。
那么，这就引出了一个问题：为什么您需要比这更具描述性地命名您的文件？任何大于此的真实需求都可能需要层次结构，此时您可以将限制乘以层次结构中的级别数加一。也就是说，如果文件在层次结构中埋入 3 层，则完整路径名称的限制为 4 × 255 = 1020 个字符。
归根结底，这个限制是人类的限制，而不是技术的限制。文件名是供人类使用的，人类实际上不需要超过 255 个字符来有效地描述文件的内容。更高的限制根本没有帮助。该限制是旧的（1983 年），因为从那时起人类还没有获得处理更长文件名的能力。
如果您问看起来奇怪的“255”值从何而来，这是基于 8 位字节大小的一些限制。 2 8是 256，这里使用的 N-1 值可能意味着他们正在使用空终止符在每个文件元数据的 256 字节字段中标记文件名字符串的结尾。
简短回答
实际上，什么限制？
脚注：
我使用精度为 0.01 克的秤进行测量。
75.5亿，截至撰写本文时。上面，我们将其四舍五入为 10 10，即我们应该到本世纪中叶。