最近，留意到 MinIO 官方博客的一篇題為“在對象存儲上實現 POSIX 訪問接口是壞主意[1]”的文章，作者以 S3FS-FUSE 為例分享了通過 POSIX 方式訪問 MinIO 中的數據時碰到了性能方面的困難，性能遠不如直接訪問 MinIO。在對結果進行分析時，作者認為是 POSIX 本身存在的缺陷導致的性能問題。這個結論與我們既有經驗有一定出入。

我們知道 POSIX 是一個有用而且廣泛應用的標準，遵循它而開發的程序可以保證不同操作系統之間的兼容性和可移植性。各行各業中常用的業務系統和應用程序，大多遵循 POSIX 標準。

隨著云計算、大數據、人工智能等技術的發展和數據存儲量的攀升，本地化應用也逐漸產生對對象存儲等彈性存儲的需求，MinIO 等對象存儲雖然提供了各種語言的 SDK，但許多傳統應用很難甚至無法修改代碼去適配對象存儲的訪問接口，這促使很多存儲產品在對象存儲的基礎上去實現 POSIX 接口來滿足這樣的剛性需求。

業內在對象存儲上實現 POSIX 接口的產品有很多，比如 Ceph、JuiceFS、Weka 等，它們都有廣泛的用戶群和大量的成功案例，在性能方面也都有不錯的表現。

誠然，我們認可 POSIX 存在較大的復雜性，需要付出很大的努力才能解決好相關的問題，但這些問題并不是無法解決。抱著尊重和求證的態度，我搭建了測試環境，采用相同的樣本和測試方法，進行了一番驗證。

測試項目

為了得到更為全面的測試結果，我將 JuiceFS 引入了對比。

JuiceFS 是開源的云原生分布式文件系統，它采用對象存儲作為數據存儲層，采用獨立的數據庫存儲元數據。提供了包括 POSIX API、S3 API、CSI Driver、HDFS API、WebDAV 在內的多種訪問方式，具有獨特的數據分塊、緩存和并發讀寫機制。JuiceFS 是文件系統，與 s3fs-fuse 等只提供簡單的從對象存儲到 POSIX 協議轉換的工具有著本質的不同。

通過將 JuiceFS 引入對比，可以更為客觀地求證以對象存儲為底層實現 POSIX 等協議的利弊。

在本文中，我會對 MinIO、JuiceFS 和 s3fs-fuse 進行以下兩項測試：

1.10GB 大文件的寫入測試

2.Pandas 小文件覆蓋寫測試

在底層存儲方面，它們均使用部署在獨立服務器上的 MinIO 實例；在測試樣本方面，10GB 文件會采用那篇文章中使用的csv[2]文件。

本文所提及的環境、軟件、腳本、樣本數據等均提供完整的代碼和說明，確保讀者可以復現環境和測試結果。

服務器及測試環境準備

兩臺配置相同的云服務器：

?System: Ubuntu 22.04 x64

?CPU: 8 cores

?RAM: 16GB

?SSD: 500GB

?Network: VPC

每臺服務器的信息如下：

Server A 的準備工作

我在 Server A 上通過 Docker 部署了 MinIO，命令如下：

#創建并進入專用目錄
mkdirminio&&cdminio

#創建配置文件
mkdirconfig
touchconfig/minio

config/minio文件中寫入以下信息：

MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=abc123abc
MINIO_VOLUMES="/mnt/data"

2.創建 MinIO 容器：

sudodockerrun-d--nameminio
-p9000:9000
-p9090:9090
-v/mnt/minio-data:/mnt/data
-v./config/minio:/etc/config.env
-e"MINIO_CONFIG_ENV_FILE=/etc/config.env"
--restartunless-stopped
minio/minioserver--console-address":9090"

3.在 MinIO 的 Web Console 中預先創建三個 buckets：

Server B 的準備工作

下載 10GB 測試樣本文件

curl-LOhttps://data.cityofnewyork.us/api/views/t29m-gskq/rows.csv?accessType=DOWNLOAD

2.安裝 mc 客戶端

mc 是 MinIO 項目開發的命令行文件管理器，可以在 Linux 命令行讀寫本地以及 S3 兼容的對象存儲。mc 的 cp 命令可以實時顯示數據拷貝的進度和速度，便于觀察各項測試。

注：為了保持測試的公平性，三種方案均采用 mc 進行寫測試。

#下載mc
wgethttps://dl.min.io/client/mc/release/linux-amd64/mc

#檢查版本
mc-v
mcversionRELEASE.2023-09-20T15-22-31Z(commit-id=38b8665e9e8649f98e6162bdb5163172e6ecc187)
Runtime:go1.21.1linux/amd64

# 安裝mc
sudoinstallmc/usr/bin

#為MinIO添加別名
mcaliassetmyhttp://172.16.254.18:9000adminabc123abc

3.安裝 s3fs-fuse

sudoaptinstalls3fs

#檢查版本
s3fs--version
AmazonSimpleStorageServiceFileSystemV1.93(commit:unknown)withOpenSSL

#設置對象存儲訪問密鑰
echoadmin:abc123abc>~/.passwd-s3fs

#修改密鑰文件權限
chmod600~/.passwd-s3fs

#創建掛載目錄
mkdirmnt-s3fs

#掛載對象存儲
s3fstest-s3fs://root/mnt-s3fs-ourl=http://172.16.254.18:9000-ouse_path_request_style

4.安裝 JuiceFS

這里使用官方提供的腳本安裝最新的 JuiceFS 社區版

#一鍵安裝腳本
curl-sSLhttps://d.juicefs.com/install|sh-

#檢查版本
juicefsversion
juicefsversion1.1.0+2023-09-04.08c4ae6

JuiceFS 是文件系統，需要先創建才能使用。除了對象存儲，還需要一個數據庫作為元數據引擎，支持多種數據庫，這里使用較常用的 Redis 作為元數據引擎。

注：我在這里將 Redis 安裝在 Server A，通過 172.16.254.18:6379 進行訪問，無密碼，安裝過程略，詳情參考 Redis 官方文檔。

#創建文件系統
juicefsformat--storageminio
--buckethttp://172.16.254.18:9000/test-juicefs
--access-keyadmin
--secret-keyabc123abc
--trash-days0
redis://172.16.254.18/1
myjfs

5.另外，我會同時以較為常用的 POSIX 和 S3 API 兩種方式訪問 JuiceFS 并分別測試它們的性能。

#創建掛載目錄
mkdir~/mnt-juicefs

#以POSIX方式掛載文件系統
juicefsmountredis://172.16.254.18/1/root/mnt-juicefs

#以S3API方式訪問文件系統
exportMINIO_ROOT_USER=admin
exportMINIO_ROOT_PASSWORD=abc123abc
juicefsgatewayredis://172.16.254.18/10.0.0.0:9000

#在mc中為JuiceFSS3API添加別名
mcaliassetjuicefshttp://172.16.254.18:9000adminabc123abc

注：JuiceFS Gateway 也可以部署在 Server A 或其他任何可聯網服務器上，因為它開放的是基于網絡訪問的 S3 API。

測試及結果

測試一：10GB 文件寫入測試

這項測試用來評估寫大文件的性能，耗時越短性能越好。這里會使用 time 命令統計寫入耗時，結果會包含三個指標：

? real：從命令開始到結束的實際時間。它包括了所有的等待時間，例如等待 I/O 操作完成、等待進程切換、等待資源等。

? user：在用戶態（用戶模式）執行的時間，也就是 CPU 用于執行用戶代碼的時間。它通常表示命令的計算工作量。

? sys：在內核態（系統模式）執行的時間，也就是 CPU 用于執行內核代碼的時間。它通常表示命令與系統調用（如文件 I/O、進程管理等）相關的工作量。

MinIO

#執行拷貝測試
timemccp./2018_Yellow_Taxi_Trip_Data.csvmy/test-minio/

MinIO 直寫 10 GB 文件的測試結果：

real0m27.651s
user0m10.767s
sys0m5.439s

s3fs-fuse

#執行拷貝測試
timemccp./2018_Yellow_Taxi_Trip_Data.csv/root/mnt-s3fs/

s3fs-fuse 寫 10 GB 文件的測試結果：

real3m6.380s
user0m0.012s
sys0m5.459s

注：雖然寫入耗時 3 分零 6 秒，但并沒有出現那篇文章所謂寫入失敗的情況。

JuiceFS POSIX 和 S3 API

分別測試 JuiceFS 的 POSIX 和 S3 API 的大文件寫性能：

#POSIX寫測試
timemccp./2018_Yellow_Taxi_Trip_Data.csv/root/mnt-juicefs/

#S3API寫測試
timemccp./2018_Yellow_Taxi_Trip_Data.csvjuicefs/myjfs/

JuiceFS POSIX 寫 10 GB 文件的測試結果：

real0m28.107s
user0m0.292s
sys0m6.930s

JuiceFS S3 API 寫 10GB 文件的測試結果：

real0m28.091s
user0m13.643s
sys0m4.142s

大文件寫結果總結

大文件寫測試（值越小，性能越好）

從測試結果來看，直接寫 MinIO 和 JuiceFS 的性能相當，均可在 30s 內完成，而 s3fs-fuse 寫入 10GB 文件耗時 3 分鐘以上，平均比前兩者慢了 6 倍左右。

在寫入大文件時，mc 會使用 Multipart API 來將文件分塊上傳到 S3 接口，而只能單線程寫入到 POSIX。JuiceFS 在大文件的順序寫也會自動將文件分塊并并發寫入到 MinIO 中，因此與直接寫 MinIO 性能相當。而 S3FS 默認先是單線程寫入到緩存盤，然后再分塊寫入到 MinIO 中，這會耗費更多寫入時間。

按照寫 10GB 文件耗時 30 秒計算，平均速度為 333 MB/s，這是云服務器 SSD 的帶寬限制，測試結果表明，MinIO 和 JuiceFS 都能打滿本地 SSD 的帶寬，它們的性能會隨著服務器云盤和網絡帶寬的提升而提升。

測試二：Pandas 小文件覆蓋寫

這項測試主要用來評估對象存儲在小文件覆蓋寫方面的性能，各個軟件的測試腳本略有不同，你可以在這里[3]找到所有腳本代碼。

Minio

#獲取測試腳本
curl-LOhttps://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-minio.py

#執行測試
python3pandas-minio.py

測試結果：

Executiontime:0.83seconds

s3fs-fuse

#獲取測試腳本
curl-LOgist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-s3fs.py

#執行測試
python3pandas-s3fs.py

測試結果：

Executiontime:0.78seconds

JuiceFS POSIX

#獲取測試腳本
curl-LOgist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-posix.py

#執行測試
python3pandas-juicefs-posix.py

測試結果：

Executiontime:0.43seconds

JuiceFS S3 API

#獲取測試腳本
curl-LOhttps://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-s3api.py

#執行測試
python3pandas-juicefs-s3api.py

測試結果：

Executiontime:0.86seconds

Pandas 小文件覆蓋寫結果總結

小文件覆蓋寫測試（值越小，性能越好）

在這項測試中，JuiceFS FUSE-POSIX 的速度最快，幾乎是其他方案的 2 倍。MinIO、s3fs-fuse、JuiceFS S3 Gateway 的速度相當。從小文件覆蓋寫的角度來看，POSIX 接口效率更高，比對象存儲接口有更好的性能表現。

測試結果

分析和總結

問題一：S3FS 為什么這么慢？

從測試數據可以清楚地看到，寫入同樣的 10GB 大文件，S3FS 需要 3 分鐘，而 MinIO 和 JuiceFS 只需要 30 秒左右，速度相差近 6 倍，這主要是由于不同的技術實現導致的。

s3fs-fuse 在寫入文件時，會優先寫入本地臨時文件，然后以分片方式上傳對象存儲。如果本地磁盤空間不足，則會以同步的方式上傳。因為它需要在本地磁盤和 S3 存儲之間進行數據復制，在處理大文件或大量文件時就會導致性能下降。

再者，S3FS 依賴底層對象存儲的元數據管理能力，當需要讀寫大量文件時，頻繁地與對象存儲交互獲取元數據也會對性能產生很大的影響。

簡單來說，寫入 S3FS 的文件體積和總量越大，相應的性能開銷也會成比例地放大。

問題二：JuiceFS 為什么更快？

同樣是通過 FUSE 進行讀寫，為什么 JuiceFS 可以與 MinIO 一樣打滿磁盤帶寬，而沒有像 S3FS 那樣出現性能問題呢？這同樣也是由技術架構決定的。

在寫入文件時，數據雖然也經由 FUSE 層處理，但 JuiceFS 通過高并發、緩存、數據分塊等技術降低了與底層對象存儲之間的通信開銷，一次性處理更多文件的讀寫請求，從而減少了等待時間和傳輸延遲。

另外，JuiceFS 采用獨立的數據庫（在本文中使用了 Redis）管理元數據，當文件量特別大時，獨立的元數據引擎能有效釋放壓力，可以更快地定位文件位置。

結論

以上數據表明，把對象存儲作為底層，在其上實現 POSIX 接口不一定會損失性能，不論是寫大文件還是小文件，JuiceFS 的性能與直接寫 MinIO 是相當的，并沒有因為訪問 POSIX 而損失底層對象存儲的性能。而在 Pandas 表格覆蓋寫方面，JuiceFS FUSE-POSIX 的性能不降反升，超過 MinIO 近兩倍。

從測試結果不難發現，某些軟件（例如 s3fs-fuse）將 S3 API 與 POSIX 接口相互轉換可能會導致對象存儲的性能損失，但它不失為一款還算方便的臨時訪問 S3 的小工具，但要想長期穩定的高性能使用，需要通過更為審慎的調研和驗證來選擇其他更適的方案。

簡單的非結構化文件歸檔存儲，直接使用 MinIO 或云上對象存儲是不錯的選擇。而對于需要進行大規模數據存儲和處理，如 AI 模型訓練、大數據分析和 Kubernetes 數據持久化等頻繁讀寫的場景，JuiceFS 的獨立元數據管理、并發讀寫和緩存機制會帶來更好的性能表現，是更值得嘗試的高性能文件系統解決方案。

審核編輯：劉清