很多企業或家庭使用者第一次建立 NAS 時，常會遇到一個疑問：
「我買的是兩顆 8TB 硬碟，組 RAID 1 之後，為什麼可用容量不是接近 8TB？」
這篇文章整合了工程師從 ADM 介面、Btrfs 底層 extent tree 一路追蹤、最後致電 ASUSTOR 原廠客服確認的完整調查結果。結論先說：
這 225GB 不是 NAS 偷吃掉的容量，也不是系統故障，而是 ASUSTOR 在 Btrfs 檔案系統初始化時，主動配置的 filesystem safety reservation——一道防止容量滿載後系統失去自救能力的安全護欄。
一、RAID 1：兩顆 8TB，可用容量只有一顆
RAID 1 的運作方式是「鏡像複製」——兩顆硬碟的內容完全相同，其中一顆是另一顆的即時備份：
資料 100% 寫入
同步複製，內容完全相同
因此容量計算是 8TB（可用）+ 8TB（保護）= 8TB 可存資料，另一顆提供的是「硬碟壞掉後資料仍然完整」的能力。這正是企業最常選用 RAID 1 的原因。
二、硬碟標示 8TB，系統看到 7.27 TB——單位換算的落差
1 TB = 1,000,000,000,000 bytes
1 TiB = 1024 × 1024 × 1024 × 1024 bytes
標示 8TB 的硬碟，換算成 NAS 使用的二進位單位約為 7.27 TiB。這不是容量消失，而是計算基準不同，硬碟拔出包裝盒那一刻起這個落差就存在了。
三、還沒放任何資料，為什麼已用了 226GB？
這是最讓使用者困惑的問題。打開 ASUSTOR ADM「資源監控 → 儲存空間」，你會看到這樣的分類：
| ADM 分類 | 使用量 | 說明 |
|---|---|---|
| 系統 | 6.25 MB | ADM 作業系統核心 |
| iSCSI LUNs / Snapshots | 0 B | 尚未建立 |
| App Central | 624.41 MB | 已安裝套件 |
| File system data and snapshots | 225.47 GB | Btrfs 安全預留區（詳見下方） |
| 可用空間 | 7.05 TB | 使用者實際可存放資料的空間 |
ADM 本身就把這 225GB 分類為 File system data and snapshots，而不是 iSCSI、快照或 App——也就是說，它屬於 Btrfs 檔案系統底層的空間，不是任何服務功能佔用的。
四、工程師從底層追蹤的結果
為了確認這 225GB 的真實去向，工程師透過 SSH 進行 Btrfs 底層分析，追蹤路徑如下：
Btrfs subvolume 清單只有三個：
base（ID 256）、.iscsi（ID 257）、.@plugins（ID 258）。沒有隱藏 subvolume，沒有快照根節點。Data 層實際配置約 227 GiB，幾乎全數被標記為 used（224 GiB）。這表示這些空間已在底層被「佔位」，但不屬於任何使用者檔案。
透過 Btrfs extent tree 追查，這 224GB 的 DATA extent reference 指向 root 257（即 .iscsi subvolume）。這是 ADM 建立 volume 時預建的系統 subvolume，與使用者是否啟用 iSCSI 服務無關。
ASUSTOR 客服明確回覆：這是 保護機制——避免儲存空間被用到太滿，導致遷移或更換硬碟時發生問題。
📋 追蹤結論
這 225GB 不是來自快照、iSCSI LUN、SSD cache 或使用者資料，而是 ASUSTOR ADM 在 Btrfs volume 初始化時，主動配置在 .iscsi subvolume 底下的 filesystem safety reservation。ADM 介面顯示為「File system data and snapshots」，原廠客服確認其用途為保護儲存系統的可用緩衝空間。
五、為什麼「滿載」對 NAS 是致命的？
Btrfs 是一個 Copy-on-Write（寫入時複製）的檔案系統——任何修改都不是直接覆蓋原本的資料，而是先寫到新的位置，確認無誤後再更新索引。這個設計讓快照、資料自我修復、RAID 重建都能安全進行，但代價是：系統需要一定的「操作空間」才能完成這些動作。
當儲存空間接近 100% 時，可能同時發生：
🅿 一個最直觀的比喻
一個 100 個車位的停車場，如果每天都停滿 100 台，看似利用率最高。但只要遇到救護車需要進入、車輛需要調度，就沒有任何緩衝。管理良好的停車場，會保留幾個「永遠不停滿的車位」。NAS 預留的這 225GB，就是那幾個關鍵空位。
六、這 225GB 佔多少比例？
以這台 NAS 的實際數字計算：
| 計算基準 | 預留量 | 比例 |
|---|---|---|
| ADM 顯示總容量（7.27 TB） | 225.47 GB | 約 3.1% |
| Btrfs 實際 TiB 計算（7,444 GiB） | 224.07 GiB | 約 3.0% |
兩種算法結果高度一致，推測 ASUSTOR 採用的是「約 volume 大小的 3%」作為保留比例，而非固定容量。這意味著若是更大容量的 NAS（如 12TB、16TB），預留空間也會等比例增加。
結論：少了的 225GB，是買來的安全性
硬碟容量被偷走
系統故障或異常
廠商灌水虛報容量
SSD Cache 佔用
Btrfs 檔案系統安全預留區
RAID 換碟重建所需操作空間
防止滿載後系統失去自救能力
原廠客服確認的保護機制設計
真正專業的儲存設備，是在容量、效能、維護性與資料安全之間取得平衡，而不是把每個 byte 都交給使用者填滿。這 225GB 的存在，讓 NAS 在未來硬碟故障、搬遷、換碟時，仍然有足夠空間完成保護動作。
附錄：管理員驗證方式
若需要向業主展示數據佐證，建議使用以下路徑：
點選 Volume 後展開分類，可直接看到「File system data and snapshots: 225.47 GB」與其他分類的明細。這是業主最直觀可驗證的介面，數字不會憑空消失。
確認 RAID 1 總容量（7.27 TB）與可用空間（7.05 TB），並對照兩顆硬碟的實際顯示容量，說明單位換算差異。
登入 NAS 後可執行
btrfs filesystem usage /volume1，直接查看 Btrfs Data/Metadata 的 allocated 與 used 數字。ASUSTOR NAS 的 SSH 環境不提供 lsblk，如需查看分割區配置可改用 df -h。#NAS
#ASUSTOR
#Btrfs
#RAID1
#工程師思路系列
作者：Mr. τ ／ 風雲網通系統有限公司 PCPiLOT
Comments