Google Drive 與主流雲端硬碟檔案系統效能深入研究

雲端硬碟的速度評測，大多聚焦在「上傳一部 4K 影片要幾分鐘」。但對開發者和重度知識管理者來說，真正的日常壓力不是大檔，而是幾萬個 markdown 筆記、git repo 裡的幾千個原始碼檔案、log archive 裡的零碎小檔——這些才是讓雲端同步變成噩夢的場景。

這篇整理六家主流服務在大量小檔案情境下的架構差異與實測數據。

一、研究範圍與前提

本研究聚焦在「大量小檔案（例如原始碼庫、筆記輸出、log）」在桌機／筆電環境下的檔案系統效能與同步行為，而非單一大檔順序吞吐量。比較對象包含 Google Drive、Dropbox、Box、Microsoft OneDrive、Apple iCloud Drive 與 MEGA，並以官方技術文章、第三方 benchmark、社群實測與工具作者經驗為主要資料來源。

二、核心技術差異總覽

Block-level sync（區塊層級同步）

所謂 block-level sync，是指檔案修改後只上傳變動區塊，而非整個檔案，可大幅改善反覆修改檔案時的同步延遲，對原始碼、Office 文件等反覆存檔情境尤其顯著。

第三方整理指出，Dropbox 與 OneDrive 已在一般檔案上廣泛採用 block-level sync，而 Google Drive、Box 等多數競品仍以整檔重傳為主，這是同步體感速度差異的主因之一。

同步引擎與 OS 整合層級

Windows 上 OneDrive 使用雲端檔案迷你過濾驅動程式 cldflt.sys 作為核心（Cloud Files Mini Filter Driver），在 kernel 層攔截檔案系統呼叫並實作 Cloud Files（Files On-Demand）語義，能更細粒度地追蹤狀態與進行 delta sync。

macOS 則廣泛使用 FSEvents 與 File Provider API 來監看檔案變更並實作「資料為 0 的佔位檔」（dataless file）行為，iCloud Drive 與新版 Dropbox/OneDrive 用同一套架構，但各家在同步根目錄、外接磁碟支援與狀態管理上策略不同，導致實際效能體驗差異。

掃描與資料庫設計

Dropbox 官方技術文章說明，其後端會將檔案切成固定大小區塊（約 4MB），以區塊 hash 列表（blocklist）代表檔案內容，同時維護 append-only metadata database，這種設計在大量檔案與多版本情境下能維持較好的查詢效率。

Box 官方建議將本機同步檔案總數維持在 10 萬個以下、總容量低於 100GB，以避免同步與掃描時間過長，間接反映其 metadata 索引對大型目錄樹的壓力。

三、各家服務小檔案效能與限制

Google Drive

多個 rclone 與同步工具使用者回報，在上傳大量小檔案至 Google Drive 時，每秒只能建立約 2 個檔案（rclone forum 實測），初始化（0%）階段等待時間長，真正傳輸階段則可利用頻寬，顯示瓶頸在 API／metadata 處理而非純傳輸速率。

另有實測顯示，Google Drive 在大檔連續上傳時，長期維持約 45Mbps 上傳與 180Mbps 下載，即使底層網路為 400Mbps 以上，Drive 仍會在 70–100Mbps 上限附近節流（Cloud Storage Explorer 評測）；10k 小檔整批上傳仍會被 API 限制與掃描成本拖慢。

第三方評測明確指出 Google Drive 並未對一般檔案提供 block-level sync，每次檔案變更都要重傳整個檔案（cloudwards.net 分析），這使得反覆修改的大量小檔在 Google Drive 上的同步延遲相對於 Dropbox/OneDrive 明顯偏高。

Linux 上常用的 google-drive-ocamlfuse、drivefs 等 FUSE 實作也普遍被評為「非常慢」，因為 metadata 與內容都需經由使用者空間 FUSE 層再走 Drive API，對小檔 IOPS 尤其不利。

Dropbox

Dropbox 從早期就將檔案切成 4MB 區塊並以 hash blocklist 管理，廣泛使用 block-level sync，只要檔案部分區塊有變更，就只需上傳變動區塊，大幅降低反覆修改文件時的延遲與頻寬消耗。

官方技術部落格介紹了 Streaming Sync 與後來的 Broccoli 壓縮和 Nucleus 同步引擎重寫，透過邊上傳邊轉發、在區塊層級做壓縮與差異同步，使多端同步延遲中位數降低超過 30%，大檔甚至可加速到 2 倍（Dropbox Tech：Broccoli）。

第三方評測與用戶回饋普遍認為，在同樣的網路環境與檔案集合下，Dropbox 的同步速度（尤其是已有大量檔案、只改少數檔案時）顯著優於 Google Drive 與 Box，主因就在於成熟的 block-level sync 與同步協定設計。

Box

Box 官方對舊版 Box Sync 明示建議，總同步檔案數量應控制在 10 萬檔以下、總容量控制在 100GB 以下，否則掃描與同步效能會明顯下降，並建議高活動度資料夾改以 Web 介面而非本機同步存取（Box Support 官方文件）。

社群使用者在以 rclone 等工具將數萬小檔搬移到 Box 時，實測建立檔案速度約為每秒 0.5 檔，相比 Google Drive 約每秒 2.5 檔顯著偏慢，且當目標目錄內檔案數達到約一千個以上時速度進一步跌到每秒 0.05 檔（rclone forum：Box 嚴重效能問題），顯示 Box 在目錄內檔案數量與 metadata 操作上有明顯擴展性瓶頸。

Microsoft OneDrive

OneDrive 早期只對 Office 格式檔案提供 block-level sync，但後續已逐步擴展到一般檔案，並在 2020 年前後完成普及，現今被普遍視為與 Dropbox 一樣具備成熟 block-level sync 的主流服務。

在 Windows 上，OneDrive 透過 kernel 層的 cldflt.sys 實作 Files On-Demand，能在大量 rename / move / delete 等純 metadata 操作時，僅需同步輕量的 metadata 封包，而非掃描整顆目錄樹。

第三方實測顯示，對 10k 檔案、25GB 的資料夾，OneDrive Files On-Demand 只需同步 metadata 並在存取時串流內容，初次同步可在 90 秒內完成，而 Google Drive 需 22–38 分鐘進行完整本機複製與驗證（Google Drive vs OneDrive Sync Speed 實測）。

Apple iCloud Drive

iCloud Drive 在 macOS 上與系統整合度極高，透過 FSEvents 與 File Provider API 實作「資料為 0 的檔案佔位」與按需下載；然而不少實測與使用者回報指出，Finder 內的 iCloud Drive 上傳與同步速度常明顯落後實際網路頻寬，長時間維持低速且優先順序似乎被系統壓低，而透過 Safari 網頁上傳同樣檔案時速度則正常，顯示瓶頸主要在 Finder / fileproviderd 管線而非網路。

iCloud Drive 的同步狀態控制相對不透明，難以強制整個目錄樹完整保留本機，亦較難細緻調整哪些目錄永遠保持離線可用，對需要嚴格掌控檔案狀態的開發情境較不友善。

MEGA

第三方評測顯示，MEGA 在一般大檔同步測試中有不錯的吞吐量表現，但測試主要偏向大檔順序傳輸而非大量小檔 IOPS。

社群使用者在以 TrueNAS 內建 Cloud Sync 對接 MEGA 時，報告實際同步速度僅約 1–2MB/s，且官方回覆指出建議改用 MEGAcmd 等工具以改善效能（TrueNAS Community 討論），可推知在大量小檔同步時，MEGA 的連線管理與檔案初始化開銷會成為瓶頸。

四、小檔案 IOPS 與檔案系統層面觀察

小檔 IOPS 為何困難

對雲端硬碟而言，上傳一個檔案通常包含：本機掃描與雜湊、與伺服器協商 metadata（路徑、權限、版本）、可能的重複資料刪除（dedup）、實際內容傳輸，以及伺服器端寫入與索引更新——任何一步都有固定成本，導致「一個檔案不管大小都要先付一筆最低手續費」。

在大量小檔情境中，這些固定成本遠大於內容傳輸本身，即使網路頻寬很大，仍會看到「每秒只能處理幾個檔案」的瓶頸。

目錄樹大小與 metadata 放大

Box 官方與第三方批評都指出，在單一同步樹下放入數萬甚至數十萬檔案時，Box Sync/Drive 在掃描與同步上的效能會急遽下降，官方甚至明確寫出「Box Drive 不適合大量內容傳輸」。

rclone 在 Google Drive 上也有類似觀察：當目錄中有非常多小檔時，初始化、列舉與建立檔案的延遲會顯著拉長，造成整體同步時間大幅增加，即使單個檔案實際上傳很快。

FUSE 虛擬檔案系統的成本

在 Linux 或某些平台上，Google Drive、MEGA 等常透過 FUSE 或類似機制將雲端存儲掛載成檔案系統，這種設計會讓每次 open/close/read/write 呼叫跨越 user-kernel 邊界並轉成 HTTP/API 呼叫，對於大量小 I/O 極為不利，相比本機磁碟操作會慢數個數量級。

相對地，Windows 上的 OneDrive Files On-Demand 與 macOS 上以 File Provider API 為基礎的 OneDrive/Dropbox/iCloud，則在 OS 提供的原生雲端檔案支援之上實作，理論上較能優化小檔 IOPS，但實際表現仍取決於各家實作品質（例如 iCloud 在 Finder 中刻意降低優先順序）。

五、實務比較與建議

整體結論

以「原始碼庫／知識庫」型工作負載來看

對以 git repo、Notion 匯出、Zettelkasten markdown、log archive 為主的大量小檔案工作負載，最關鍵的是：反覆修改時是否有 block-level / delta sync、客戶端在掃描與比對變更時的 metadata 效率，以及對大量檔案／深層目錄樹的擴展性。

在這些面向下：

• Dropbox 與 OneDrive 是優先考慮，因為有成熟的 block-level sync 與較佳的多端狀態協調機制
• Google Drive 雖然在通用性與整合度（Gmail、Docs）上有優勢，但大量小檔 IOPS 明顯落後，常見 workaround 是先本機壓縮打包再上傳，或改用 Syncthing 在本機與伺服器間同步
• Box 不建議作為大型原始碼或知識庫的主同步層，較適合公司文件協作平台
• iCloud Drive 與 MEGA 各有優勢（蘋果生態整合、端對端加密），但若以開發者工作負載為核心，通常不會是首選同步層

實務調校建議

無論選用哪家服務，在「大量小檔」情境都可考慮以下策略：

• 避免讓單一同步根目錄承載過多檔案與層級，適度拆分成多個同步資料夾，減少 metadata 掃描成本
• 對非常細碎的檔案（CI 臨時檔、build artifacts、log）優先採用本機儲存或 Syncthing 管理，再定期打包（tar/zip）成較大檔案上傳雲端備份
• 在 OneDrive / Dropbox 等支援 Files On-Demand 或 selective sync 的平台上，僅對活躍工作集啟用「Always keep on this device」，其餘以按需下載方式保留，對包含 10k 檔案以上的專案尤其有效
• 在 macOS 與 Windows 上，盡量使用官方桌面 client 而非第三方 FUSE 掛載；Linux 則需接受 FUSE 帶來的效能折扣，或改走 rsync/Syncthing + 定期大檔備份的架構

五點五、實際使用 Obsidian Vault 的第一手觀察

以上數據都是第三方實測，但最直接的觀察來自自己的知識庫。

我的 Obsidian Vault 裝了幾千個 markdown 筆記，全部都是小檔案，平均不到 10KB。這正是讓雲端同步最難受的工作負載。

Google Drive：同步延遲 + 檔案衝突

把 Vault 放在 Google Drive 同步資料夾後，最常見的問題是：在 A 裝置修改的筆記，B 裝置遲遲沒有更新。多裝置同時開著 Obsidian 時，更容易出現衝突複本（Conflicted Copy），原因正是 Google Drive 缺乏 block-level sync——每次存檔都是整檔重傳，時序一錯就產生衝突。

OneDrive：設定檔衝突

OneDrive 的問題集中在 .obsidian/ 目錄下的 JSON 設定檔。Obsidian 會頻繁讀寫這些設定檔（workspace、plugin 狀態、快取），OneDrive 的同步引擎在這類「頻繁小改動」的 JSON 上容易產生衝突鎖，導致外掛設定被複寫或 workspace 狀態跑掉。

Dropbox：目前最穩定的選擇

換到 Dropbox 之後，上述問題幾乎消失。原因和第三方評測吻合：block-level sync 讓每次筆記存檔只傳變動的區塊，多裝置狀態協調也更準確。macOS 和 iOS 的 Files App 標準目錄整合也是實際優點——Obsidian iOS App 透過 Dropbox 可以直接存取，不需要額外設定。

iCloud：蘋果生態的次選方案

Dropbox 需要付費時，iCloud 是蘋果裝置的備援方案。在 macOS + iOS 的組合下同步基本穩定，但偶爾會在 Finder 中看到上傳卡住、進度條停在某個百分比的情況，重現了上面提到的「fileproviderd 優先順序被系統壓低」現象。Linux 不支援，對跨平台使用者不適合。

MEGA：可用但連線開銷明顯

MEGA 在初次全量同步時速度可接受，但每次 Obsidian 啟動時，MEGA 客戶端掃描 Vault 的延遲比 Dropbox 明顯，體感上「Obsidian 打開到可以用」的時間較長，和大量小檔連線初始化開銷的推論一致。

六、結語

從檔案系統與同步架構層級來看，Google Drive 在通用雲端儲存領域仍具優勢，但在「大量小檔 IOPS／原始碼庫」這種較偏工程的工作負載下，其缺乏 block-level sync、API 節流與 metadata 處理效能限制，讓其在實際體感上顯著落後 Dropbox 與 OneDrive。

對需要在多台桌機／筆電間同步大型 repo 與知識庫的使用情境，更適合將 Dropbox 或 OneDrive 視為主同步層，再以雲端儲存（含 Google Drive）作為次要備份層，或採用「本機／自架同步 + 雲端大檔備份」的分層架構，以在效能、可靠性與成本間取得平衡。

References

1. What is Block-Level Sync & How Does It Work?
2. Transfer speed (small files) - rclone forum
3. Streaming File Synchronization - Dropbox Tech Blog
4. Google Drive vs OneDrive Sync Speed
5. Google Drive Review 2026
6. What Is Block Level Sync & How Does It Work in 2026?
7. Maximizing Box Sync Performance - Box Support
8. Rclone very slow uploading small files to Box
9. Broccoli: Syncing faster by syncing less - Dropbox Tech
10. Why is iCloud Drive slow on macOS? - Reddit
11. MEGA Review - experte.com
12. Slow cloud sync MEGA.nz - TrueNAS Community