M11 · CTF
容器、volume role 與 copy-on-write snapshot
在 APFS 結構視圖裡找出哪個 volume 是唯讀且被封印的 System、哪個是可寫的 Data， 並用共享 extent + refcount 模型解釋：為什麼 clone/snapshot「幾乎不佔空間」、 以及為什麼刪了大檔卻沒釋放空間（某個 snapshot 仍釘住那些 extent）。
APFS clone / COW
檔案 A
共享 extentCOW 私有 extent邏輯大小 6 塊 · 實體佔用 6 塊（共享只算一次）
clonefile 複製＝兩檔共享同一批 extent，不佔額外空間；改寫某塊才 copy-on-write 出新 extent（只有那塊變私有）。snapshot 同理：對「當下狀態」釘一份共享參照，之後的改動才分裂——M05 的 SSV seal 就是蓋在這種 snapshot 上。教學抽象，非真實 APFS 結構。
過關目標
- 讓 apfs.volume.system.readonly 達到 true
- 讓 apfs.volume.system.sealed 達到 true
- 讓 apfs.snapshot.sharedExtent.refcount 達到 "shared"
- 用自己的話解釋：用「共享 extent + refcount + copy-on-write」解釋：為什麼 snapshot 一開始幾乎不佔空間， 以及為什麼刪了大檔空間卻沒釋放？
解答是「操作模擬器到對的狀態 + 能說出原理」，非提交 flag 字串。互動式自動評分為 roadmap 項目；目前以自我檢核完成。
提示
卡住時
System 卷唯讀且 Sealed: Yes；Data 卷可寫，掛在 /System/Volumes/Data。兩者靠 firmlink 融合成單一 /。
走錯方向時
snapshot 不複製資料，只把當時的 extent 用 refcount 釘住；之後 volume 寫入走 copy-on-write，新舊各指各的 extent。
想更深入
refcount 不歸零就不回收——刪了檔但 snapshot 還指著那些 extent，空間就不會釋放。這正是 M14 取證能挖出被刪檔的原因。
相關指令
diskutills