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