當提到文件系統(tǒng)時，大部分人都很陌生。但實際上我們幾乎每天都會使用它。比如，大家打開 Windows、macOS 或者 Linux，不管是用資源管理器還是 Finder，都是在和文件系統(tǒng)打交道。

如果大家曾經(jīng)手動安裝過操作系統(tǒng)，一定會記得在第一次安裝時需要格式化磁盤，格式化時就需要為磁盤選擇使用哪個文件系統(tǒng)。

維基百科上的關(guān)于文件系統(tǒng)[1]的定義是：

In computing, file system is a method and data structure that the operating system uses to control how data is stored and retrieved.

簡而言之，文件系統(tǒng)的任務(wù)是管理存儲介質(zhì)（例如磁盤、SSD、CD、磁帶等）上的數(shù)據(jù)。

在文件系統(tǒng)中最基礎(chǔ)的概念就是文件和目錄，所有的數(shù)據(jù)都會對應(yīng)一個文件，通過目錄以樹形結(jié)構(gòu)來管理和組織這些數(shù)據(jù)。

基于文件和目錄的組織結(jié)構(gòu)，可以進行一些更高級的配置，比如給文件配置權(quán)限、統(tǒng)計文件的大小、修改時間、限制文件系統(tǒng)的容量上限等。

以下羅列了一些在不同操作系統(tǒng)中比較常見的文件系統(tǒng)：

? Linux：ext4、XFS、Btrfs

? Windows：NTFS、FAT32

? macOS：APFS、HFS+

（圖片來源：《Modern Operating Systems》10.2.5 小節(jié)）

上圖是 Linux 內(nèi)核的架構(gòu)，左邊 Virtual file system 區(qū)域，也就是虛擬文件系統(tǒng)簡稱 VFS。它的作用是為了幫助 Linux 去適配不同的文件系統(tǒng)而設(shè)計的，VFS 提供了通用的文件系統(tǒng)接口，不同的文件系統(tǒng)實現(xiàn)需要去適配這些接口。

日常使用 Linux 的時候，所有的系統(tǒng)調(diào)用請求都會先到達 VFS，然后才會由 VFS 向下請求實際使用的文件系統(tǒng)。

文件系統(tǒng)的設(shè)計者需要遵守 VFS 的接口協(xié)議來設(shè)計文件系統(tǒng)，接口是共享的，但是文件系統(tǒng)具體實現(xiàn)是不同的，每個文件系統(tǒng)都可以有自己的實現(xiàn)方式。文件系統(tǒng)再往下是存儲介質(zhì)，會根據(jù)不同的存儲介質(zhì)再去組織存儲的數(shù)據(jù)形式。

一次寫操作的請求流程 （圖片來源：《Linux Kernel Development》第 13 章 Filesystem Abstraction Layer）

上圖是一次寫操作的請求流程，在 Linux 里寫文件，其實就是一次write()系統(tǒng)調(diào)用。當你調(diào)用write()操作請求的時候，它會先到達 VFS，再由 VFS 去調(diào)用文件系統(tǒng)，最后再由文件系統(tǒng)去把實際的數(shù)據(jù)寫到本地的存儲介質(zhì)。

目錄樹（圖片來源：《Modern Operating Systems》4.2.2 小節(jié)）

上圖是一個目錄樹的結(jié)構(gòu)，在文件系統(tǒng)里面，所有數(shù)據(jù)的組織形式都是這樣一棵樹的結(jié)構(gòu)，從最上面的根節(jié)點往下，有不同的目錄和不同的文件。

這顆樹的深度是不確定的，相當于目錄的深度是不確定的，是由每個用戶來決定的，樹的葉子節(jié)點就是每一個文件。

文件描述符與 inode

（圖片來源：《Modern Operating Systems》10.6.3 小節(jié)）

最右邊的 inode 就是每個文件系統(tǒng)內(nèi)部的數(shù)據(jù)結(jié)構(gòu)。這個 inode 有可能是一個目錄，也有可能是一個普通的文件。Inode 里面會包含關(guān)于文件的一些元信息，比如創(chuàng)建時間、創(chuàng)建者、屬于哪個組以及權(quán)限信息、文件大小等。此外每個 inode 里面還會有一些指針或者索引指向?qū)嶋H物理存儲介質(zhì)上的數(shù)據(jù)塊。

以上就是實際去訪問一個單機文件系統(tǒng)時，可能會涉及到的一些數(shù)據(jù)結(jié)構(gòu)和流程。作為一個引子，讓大家對于文件系統(tǒng)有一個比較直觀的認識。

分布式文件系統(tǒng)架構(gòu)設(shè)計

單機的文件系統(tǒng)已經(jīng)能夠滿足我們大部分使用場景的需求，管理很多日常需要存儲的數(shù)據(jù)。但是隨著時代的發(fā)展以及數(shù)據(jù)的爆發(fā)增長，對于數(shù)據(jù)存儲的需求也是在不斷的增長，分布式文件系統(tǒng)應(yīng)運而生。

上面列了一些大家相對比較熟悉或者使用比較多的分布式文件系統(tǒng)，這里面有開源的文件系統(tǒng)，也有公司內(nèi)部使用的閉源產(chǎn)品。從這張圖可以看到一個非常集中的時間點，2000 年左右有一大批的分布式系統(tǒng)誕生，這些分布式文件系統(tǒng)至今在我們?nèi)粘９ぷ髦谢蚨嗷蛏龠€是會接觸到。在 2000 年之前也有各種各樣的共享存儲、并行文件系統(tǒng)、分布式文件系統(tǒng)，但基本上都是基于一些專用的且比較昂貴的硬件來構(gòu)建的。

自 2003 年 Google 的 GFS（Google File System）論文公開發(fā)表以來，很大程度上影響了后面一大批分布式系統(tǒng)的設(shè)計理念和思想。GFS 證明了我們可以用相對廉價的通用計算機，來組建一個足夠強大、可擴展、可靠的分布式存儲，完全基于軟件來定義一個文件系統(tǒng)，而不需要依賴很多專有或者高昂的硬件資源，才能去搭建一套分布式存儲系統(tǒng)。

因此 GFS 很大程度上降低了分布文件系統(tǒng)的使用門檻，所以在后續(xù)的各個分布式文件系統(tǒng)上都可以或多或少看到 GFS 的影子。比如雅虎開源的 HDFS 它基本上就是按照 GFS 這篇論文來實現(xiàn)的，HDFS 也是目前大數(shù)據(jù)領(lǐng)域使用最廣泛的存儲系統(tǒng)。

上圖第四列的「POSIX 兼容」表示這個分布式文件系統(tǒng)對 POSIX 標準的兼容性。POSIX（Portable Operating System Interface）是用于規(guī)范操作系統(tǒng)實現(xiàn)的一組標準，其中就包含與文件系統(tǒng)有關(guān)的標準。所謂 POSIX 兼容，就是滿足這個標準里面定義的一個文件系統(tǒng)應(yīng)該具備的所有特征，而不是只具備個別，比如 GFS，它雖然是一個開創(chuàng)性的分布式文件系統(tǒng)，但其實它并不是 POSIX 兼容的文件系統(tǒng)。

Google 當時在設(shè)計 GFS 時做了很多取舍，它舍棄掉了很多傳統(tǒng)單機文件系統(tǒng)的特性，保留了對于當時 Google 搜索引擎場景需要的一些分布式存儲的需求。所以嚴格上來說，GFS 并不是一個 POSIX 兼容的文件系統(tǒng)，但是它給了大家一個啟發(fā)，還可以這樣設(shè)計分布式文件系統(tǒng)。

接下來我會著重以幾個相對有代表性的分布式文件系統(tǒng)架構(gòu)為例，給大家介紹一下，如果要設(shè)計一個分布式文件系統(tǒng)，大概會需要哪些組件以及可能會遇到的一些問題。

GFS

（圖片來源：The Google File System 論文）

首先還是以提到最多的 GFS 為例，雖然它在 2003 年就公布了，但它的設(shè)計我認為至今也是不過時的，有很多值得借鑒的地方。GFS 的主要組件可以分為三塊，最左邊的 GFS client 也就是它的客戶端，然后就是中間的 GFS master 也就是它的元數(shù)據(jù)節(jié)點，最下面兩塊是 GFS chunkserver 就是數(shù)據(jù)實際存儲的節(jié)點，master 和 chunkserver 之間是通過網(wǎng)絡(luò)來通信，所以說它是一個分布式的文件系統(tǒng)。Chunkserver 可以隨著數(shù)據(jù)量的增長不斷地橫向擴展。

其中 GFS 最核心的兩塊就是 master 和 chunkserver。我們要實現(xiàn)一個文件系統(tǒng)，不管是單機還是分布式，都需要去維護文件目錄、屬性、權(quán)限、鏈接等信息，這些信息是一個文件系統(tǒng)的元數(shù)據(jù)，這些元數(shù)據(jù)信息需要在中心節(jié)點 master 里面去保存。Master 也包含一個樹狀結(jié)構(gòu)的元數(shù)據(jù)設(shè)計。

當要存儲實際的應(yīng)用數(shù)據(jù)時，最終會落到每一個 chunkserver 節(jié)點上，然后 chunkserver 會依賴本地操作系統(tǒng)的文件系統(tǒng)再去存儲這些文件。

Chunkserver 和 master、client 之間互相會有連接，比如說 client 端發(fā)起一個請求的時候，需要先從 master 獲取到當前文件的元數(shù)據(jù)信息，再去和 chunkserver 通信，然后再去獲取實際的數(shù)據(jù)。在 GFS 里面所有的文件都是分塊（chunk）存儲，比如一個 1GB 的大文件，GFS 會按照一個固定的大?。?4MB）對這個文件進行分塊，分塊了之后會分布到不同的 chunkserver 上，所以當你讀同一個文件時其實有可能會涉及到和不同的 chunkserver 通信。

同時每個文件的 chunk 會有多個副本來保證數(shù)據(jù)的可靠性，比如某一個 chunkserver 掛了或者它的磁盤壞了，整個數(shù)據(jù)的安全性還是有保障的，可以通過副本的機制來幫助你保證數(shù)據(jù)的可靠性。這是一個很經(jīng)典的分布式文件系統(tǒng)設(shè)計，現(xiàn)在再去看很多開源的分布式系統(tǒng)實現(xiàn)都或多或少有 GFS 的影子。

這里不得不提一下，GFS 的下一代產(chǎn)品: Colossus。由于 GFS 的架構(gòu)設(shè)計存在明顯的擴展性問題，所以 Google 內(nèi)部基于 GFS 繼續(xù)研發(fā)了 Colossus。Colossus 不僅為谷歌內(nèi)部各種產(chǎn)品提供存儲能力，還作為谷歌云服務(wù)的存儲底座開放給公眾使用。Colossus 在設(shè)計上增強了存儲的可擴展性，提高了可用性，以處理大規(guī)模增長的數(shù)據(jù)需求。下面即將介紹的 Tectonic 也是對標 Colossus 的存儲系統(tǒng)。篇幅關(guān)系，這篇博客不再展開介紹 Colossus，有興趣的朋友可以閱讀官方博客[2]。

Tectonic

（圖片來源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）

Tectonic 是 Meta（Facebook）內(nèi)部目前最大的一個分布式文件系統(tǒng)。Tectonic 項目大概在 2014 年就開始做了（之前被叫做 Warm Storage），但直到 2021 年才公開發(fā)表論文來介紹整個分布式文件系統(tǒng)的架構(gòu)設(shè)計。

在研發(fā) Tectonic 之前，Meta 公司內(nèi)部主要使用 HDFS、Haystack 和 f4 來存儲數(shù)據(jù)，HDFS 用在數(shù)倉場景（受限于單集群的存儲容量，部署了數(shù)十個集群），Haystack 和 f4 用在非結(jié)構(gòu)化數(shù)據(jù)存儲場景。Tectonic 的定位即是在一個集群里滿足這 3 種存儲支撐的業(yè)務(wù)場景需求。和 GFS 一樣，Tectonic 也主要由三部分構(gòu)成，分別是 Client Library、Metadata Store 和 Chunk Store。

Tectonic 比較創(chuàng)新的點在于它在 Metadata 這一層做了分層處理，以及存算分離的架構(gòu)設(shè)計。從架構(gòu)圖可以看到 Metadata 分了三層：Name layer、File layer 和 Block layer。

傳統(tǒng)分布式文件系統(tǒng)會把所有的元數(shù)據(jù)都看作同一類數(shù)據(jù)，不會把它們顯式區(qū)分。在 Tectonic 的設(shè)計中，Name layer 是與文件的名字或者目錄結(jié)構(gòu)有關(guān)的元數(shù)據(jù)，F(xiàn)ile layer 是跟當前文件本身的一些屬性相關(guān)的數(shù)據(jù)，Block layer 是每一個數(shù)據(jù)塊在 Chunk Store 位置的元數(shù)據(jù)。

Tectonic 之所以要做這樣一個分層的設(shè)計是因為它是一個非常大規(guī)模的分布式文件系統(tǒng)，特別是在 Meta 這樣的量級下（EB 級數(shù)據(jù)）。在這種規(guī)模下，對于 Metadata Store 的負載能力以及擴展性有著非常高的要求。

第二點創(chuàng)新在于元數(shù)據(jù)的存算分離設(shè)計，前面提到這三個 layer 其實是無狀態(tài)的，可以根據(jù)業(yè)務(wù)負載去橫向擴展。但是上圖中的 Key-value Store 是一個有狀態(tài)的存儲，layer 和 Key-value Store 之間通過網(wǎng)絡(luò)通信。

Key-value Store 并不完全是 Tectonic 自己研發(fā)的，而是用了 Meta 內(nèi)部一個叫做 ZippyDB 的分布式 KV 存儲來支持元數(shù)據(jù)的存儲。ZippyDB 是基于 RocksDB 以及 Paxos 共識算法來實現(xiàn)的一個分布式 KV 存儲。Tectonic 依賴 ZippyDB 的 KV 存儲以及它提供的事務(wù)來保證整個文件系統(tǒng)元信息的一致性和原子性。

這里的事務(wù)功能是非常重要的一點，如果要實現(xiàn)一個大規(guī)模的分布式文件系統(tǒng)，勢必要把 Metadata Store 做橫向擴展。橫向擴展之后就涉及數(shù)據(jù)分片，但是在文件系統(tǒng)里面有一個非常重要的語義是強一致性，比如重命名一個目錄，目錄里面會涉及到很多的子目錄，這個時候要怎么去高效地重命名目錄以及保證重命名過程中的一致性，是分布式文件系統(tǒng)設(shè)計中是一個非常重要的點，也是業(yè)界普遍認為的難點。

Tectonic 的實現(xiàn)方案就是依賴底層的 ZippyDB 的事務(wù)特性來保證當僅涉及單個分片的元數(shù)據(jù)時，文件系統(tǒng)操作一定是事務(wù)性以及強一致性的。但由于 ZippyDB 不支持跨分片的事務(wù)，因此在處理跨目錄的元數(shù)據(jù)請求（比如將文件從一個目錄移動到另一個目錄）時 Tectonic 無法保證原子性。

在 Chunk Store 層 Tectonic 也有創(chuàng)新，上文提到 GFS 是通過多副本的方式來保證數(shù)據(jù)的可靠性和安全性。多副本最大的弊端在于它的存儲成本，比如說你可能只存了1TB 的數(shù)據(jù)，但是傳統(tǒng)來說會保留三個副本，那么至少需要 3TB 的空間來存儲，這樣使得存儲成本成倍增長。

對于小數(shù)量級的文件系統(tǒng)可能還好，但是對于像 Meta 這種 EB 級的文件系統(tǒng)，三副本的設(shè)計機制會帶來非常高昂的成本，所以他們在 Chunk Store 層使用 EC（Erasure Code）也就是糾刪碼的方式去實現(xiàn)。通過這種方式可以只用大概 1.2~1.5 倍的冗余空間，就能夠保證整個集群數(shù)據(jù)的可靠性和安全性，相比三副本的冗余機制節(jié)省了很大的存儲成本。Tectonic 的 EC 設(shè)計細到可以針對每一個 chunk 進行配置，是非常靈活的。

同時 Tectonic 也支持多副本的方式，取決于上層業(yè)務(wù)需要什么樣的存儲形式。EC 不需要特別大的的空間就可以保證整體數(shù)據(jù)的可靠性，但是 EC 的缺點在于當數(shù)據(jù)損壞或丟失時重建數(shù)據(jù)的成本很高，需要額外消耗更多計算和 IO 資源。

通過論文我們得知目前 Meta 最大的 Tectonic 集群大概有四千臺存儲節(jié)點，總的容量大概有 1590PB，有 100 億的文件量，這個文件量對于分布式文件系統(tǒng)來說，也是一個比較大的規(guī)模。在實踐中，百億級基本上可以滿足目前絕大部分的使用場景。

（圖片來源：Facebook’s Tectonic Filesystem: Efficiency from Exascale 論文）

再來看一下 Tectonic 中 layer 的設(shè)計，Name、File、Block 這三個 layer 實際對應(yīng)到底層的 KV 存儲里的數(shù)據(jù)結(jié)構(gòu)如上圖所示。比如說 Name layer 這一層是以目錄 ID 作為 key 進行分片，F(xiàn)ile layer 是通過文件 ID 進行分片，Block layer 是通過塊 ID 進行分片。

Tectonic 把分布式文件系統(tǒng)的元數(shù)據(jù)抽象成了一個簡單的 KV 模型，這樣可以非常好的去做橫向擴展以及負載均衡，可以有效防止數(shù)據(jù)訪問的熱點問題。

JuiceFS

JuiceFS 誕生于 2017 年，比 GFS 和 Tectonic 都要晚，相比前兩個系統(tǒng)的誕生年代，外部環(huán)境已經(jīng)發(fā)生了翻天覆地的變化。

首先硬件資源已經(jīng)有了突飛猛進的發(fā)展，作為對比，當年 Google 機房的網(wǎng)絡(luò)帶寬只有 100Mbps（數(shù)據(jù)來源：The Google File System 論文），而現(xiàn)在 AWS 上機器的網(wǎng)絡(luò)帶寬已經(jīng)能達到 100Gbps，是當年的 1000 倍！

其次云計算已經(jīng)進入了主流市場，不管是公有云、私有云還是混合云，企業(yè)都已經(jīng)邁入了「云時代」。而云時代為企業(yè)的基礎(chǔ)設(shè)施架構(gòu)帶來了全新挑戰(zhàn)，傳統(tǒng)基于 IDC 環(huán)境設(shè)計的基礎(chǔ)設(shè)施一旦想要上云，可能都會面臨種種問題。如何最大程度上發(fā)揮云計算的優(yōu)勢是基礎(chǔ)設(shè)施更好融入云環(huán)境的必要條件，固守陳規(guī)只會事倍功半。

同時，GFS 和 Tectonic 都是僅服務(wù)公司內(nèi)部業(yè)務(wù)的系統(tǒng)，雖然規(guī)模很大，但需求相對單一。而 JuiceFS 定位于服務(wù)廣大外部用戶、滿足多樣化場景的需求，因而在架構(gòu)設(shè)計上與這兩個文件系統(tǒng)也大有不同。

基于這些變化和差異，我們再來看看 JuiceFS 的架構(gòu)。同樣的，JuiceFS 也是由 3 部分組成：元數(shù)據(jù)引擎、數(shù)據(jù)存儲和客戶端。雖然大體框架上類似，但其實每一部分的設(shè)計 JuiceFS 都有著一些不太一樣的地方。

首先是數(shù)據(jù)存儲這部分，相比 GFS 和 Tectonic 使用自研的數(shù)據(jù)存儲服務(wù)，JuiceFS 在架構(gòu)設(shè)計上順應(yīng)了云原生時代的特點，直接使用對象存儲作為數(shù)據(jù)存儲。前面看到 Tectonic 為了存儲 EB 級的數(shù)據(jù)用了 4000 多臺服務(wù)器，可想而知，如此大規(guī)模存儲集群的運維成本也必然不小。對于普通用戶來說，對象存儲的好處是開箱即用、容量彈性，運維復(fù)雜度陡然下降。對象存儲也支持 Tectonic 中使用的 EC 特性，因此存儲成本相比一些多副本的分布式文件系統(tǒng)也能降低不少。

但是對象存儲的缺點也很明顯，例如不支持修改對象、元數(shù)據(jù)性能差、無法保證強一致性、隨機讀性能差等。這些問題都被 JuiceFS 設(shè)計的獨立元數(shù)據(jù)引擎，Chunk、Slice、Block 三層數(shù)據(jù)架構(gòu)設(shè)計，以及多級緩存解決了。

其次是元數(shù)據(jù)引擎，JuiceFS 可使用一些開源數(shù)據(jù)庫作為元數(shù)據(jù)的底層存儲。這一點和 Tectonic 很像，但 JuiceFS 更進了一步，不僅支持分布式 KV，還支持 Redis、關(guān)系型數(shù)據(jù)庫等存儲引擎，讓用戶可以靈活地根據(jù)自己的使用場景選擇最適合的方案，這是基于 JuiceFS 定位為一款通用型文件系統(tǒng)所做出的架構(gòu)設(shè)計。使用開源數(shù)據(jù)庫的另一個好處是這些數(shù)據(jù)庫在公有云上通常都有全托管服務(wù)，因此對于用戶來說運維成本幾乎為零。

前面提到 Tectonic 為了保證元數(shù)據(jù)的強一致性選擇了 ZippyDB 這個支持事務(wù)的 KV 存儲，但 Tectonic 也只能保證單分片元數(shù)據(jù)操作的事務(wù)性，而 JuiceFS 對于事務(wù)性有著更嚴格的要求，需要保證全局強一致性（即要求跨分片的事務(wù)性）。因此目前支持的所有數(shù)據(jù)庫都必須具有單機或者分布式事務(wù)特性，否則是沒有辦法作為元數(shù)據(jù)引擎接入進來的（一個例子就是 Redis Cluster 不支持跨 slot 的事務(wù)）。基于可以橫向擴展的元數(shù)據(jù)引擎（比如 TiKV），JuiceFS 目前已經(jīng)能做到在單個文件系統(tǒng)中存儲 200 多億個文件，滿足企業(yè)海量數(shù)據(jù)的存儲需求。

上圖是使用 KV 存儲（比如 TiKV）作為 JuiceFS 元數(shù)據(jù)引擎時的數(shù)據(jù)結(jié)構(gòu)設(shè)計，如果對比 Tectonic 的設(shè)計，既有相似之處也有一些大的差異。比如第一個 key，在 JuiceFS 的設(shè)計里沒有對文件和目錄進行區(qū)分，同時文件或目錄的屬性信息也沒有放在 value 里，而是有一個單獨的 key 用于存儲屬性信息（即第三個 key）。

第二個 key 用于存儲數(shù)據(jù)對應(yīng)的塊 ID，由于 JuiceFS 基于對象存儲，因此不需要像 Tectonic 那樣存儲具體的磁盤信息，只需要通過某種方式得到對象的 key 即可。在 JuiceFS 的存儲格式[3]中元數(shù)據(jù)分了 3 層：Chunk、Slice、Block，其中 Chunk 是固定的 64MiB 大小，所以第二個 key 中的chunk_index是可以通過文件大小、offset 以及 64MiB 直接計算得出。通過這個 key 獲取到的 value 是一組 Slice 信息，其中包含 Slice 的 ID、長度等，結(jié)合這些信息就可以算出對象存儲上的 key，最終實現(xiàn)讀取或者寫入數(shù)據(jù)。

最后有一點需要特別注意，為了減少執(zhí)行分布式事務(wù)帶來的開銷，第三個 key 在設(shè)計上需要靠近前面兩個 key，確保事務(wù)盡量在單個元數(shù)據(jù)引擎節(jié)點上完成。不過如果分布式事務(wù)無法避免，JuiceFS 底層的元數(shù)據(jù)引擎也支持（性能略有下降），確保元數(shù)據(jù)操作的原子性。

最后來看看客戶端的設(shè)計。JuiceFS 和另外兩個系統(tǒng)最大的區(qū)別就是這是一個同時支持多種標準訪問方式的客戶端，包括 POSIX、HDFS、S3、Kubernetes CSI 等。GFS 的客戶端基本可以認為是一個非標準協(xié)議的客戶端，不支持 POSIX 標準，只支持追加寫，因此只能用在單一場景。Tectonic 的客戶端和 GFS 差不多，也不支持 POSIX 標準，只支持追加寫，但 Tectonic 采用了一種富客戶端的設(shè)計，把很多功能都放在客戶端這一邊來實現(xiàn)，這樣也使得客戶端有著最大的靈活性。此外 JuiceFS 的客戶端還提供了緩存加速特性，這對于云原生架構(gòu)下的存儲分離場景是非常有價值的。

結(jié)語

文件系統(tǒng)誕生于上個世紀 60 年代，隨著時代的發(fā)展，文件系統(tǒng)也在不斷演進。一方面由于互聯(lián)網(wǎng)的普及，數(shù)據(jù)規(guī)模爆發(fā)式增長，文件系統(tǒng)經(jīng)歷了從單機到分布式的架構(gòu)升級，Google 和 Meta 這樣的公司便是其中的引領(lǐng)者。

另一方面，云計算的誕生和流行推動著云上存儲的發(fā)展，企業(yè)用云進行備份和存檔已逐漸成為主流，一些在本地機房進行的高性能計算、大數(shù)據(jù)場景，也已經(jīng)開始向云端遷移，這些對性能要求更高的場景給文件存儲提出了新的挑戰(zhàn)。JuiceFS 誕生于這樣的時代背景，作為一款基于對象存儲的分布式文件系統(tǒng)，JuiceFS 希望能夠為更多不同規(guī)模的公司和更多樣化的場景提供可擴展的文件存儲方案。

審核編輯：劉清