ZFS 限制背後的意義是什麼？
根據 Wikipedia，ZFS 有以下限制：
最大限度。卷大小：256 萬億 yobibytes（2 128字節）
最大限度。文件大小：16 exbibytes（2 64字節）
最大限度。文件數：
- 每個目錄：2 48
- 每個文件系統：無限制
最大限度。文件名長度：255 個 ASCII 字元（對於 Unicode 等多字節字元編碼更少）
為什麼會有這些限制？是什麼在內部限制了這些事情？為什麼 ZFS 不能具有理論上無限的捲大小或文件名長度等等？
是什麼在內部限制了這些事情？
長答案
ZFS 的限制基於固定大小的整數，因為這是在電腦中進行算術運算的最快方法。
另一種方法稱為任意精度算術，但它本質上很慢。這就是為什麼任意精度算術是大多數程式語言中的附加庫，而不是預設的算術運算方式。也有例外，但這些通常是面向數學的DSL
bc，例如Wolfram Language。如果你想要快速算術，你可以使用固定大小的單詞，句點。
在電腦的 RAM 中，任意精度算術對速度的影響已經足夠糟糕了，但是當文件系統不知道它需要進行多少次讀取才能將它需要的所有數字載入到 RAM 中時，這將是非常昂貴的。基於任意大小整數的文件系統必須將多個塊中的每個數字拼湊在一起，相對於預先知道其元數據塊有多大的文件系統，需要來自多個磁碟命中的大量額外 I/O。
現在讓我們討論每個限制的實際導入：
最大限度。卷大小
2 128字節實際上已經是無限的了。我們可以將這個數字寫成大約 10 38字節，這意味著為了達到這個限制，你必須有一個地球大小的 ZFS 池，其中10 50 個原子中的每一個都用於儲存數據，並且每個字節由不大於 10 12 個原子的元素儲存。
10 12 個原子聽起來很多，但它只有大約 47 皮克的矽。
microSD 儲存的數據密度（克）為 2.5×10 -13 g/byte矽，但你不能忽視封裝，因為我們的地球電腦中也需要一些封裝；我們假設塑膠的低密度和金屬引腳的高密度平均與硅的密度大致相同。我們在這裡還需要一些斜率來考慮晶片間互連等。
一個皮克是 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 儲存陣列的個人小片中儲存大約十億個最大大小的文件。
（如果在這個例子中我們的儲存陣列仍然是一個星球的大小，請記住它必須那麼大才能達到上面的第一個限制，所以在這個例子中繼續使用它是公平的這裡。）
在 ZFS 下，每個文件的最大文件大小為 16 EiB ，比 ext4 的最大卷大小大 16 倍，而 ext4 在今天被認為大得離譜。
想像一下，有人使用他們的 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，我們應該在本世紀中葉達到。