btrfs 可行性假設 & 資訊

• 假設: 如果 share 裡有 fast copy, 刪除時對 user 體驗影響不大, 刪除時間不會變長，unpin 可在背景處理 TBD
  • 因為 unpin 的查找有 pin metadata 加速，而且可以從 drop extent 延後到背景處理 (commit transation or performance metadata )
  • CKYa 想先做一版仍放在 drop extent 的看看
    • 目前放 drop extent 的話，如果 clone 次數很多，刪除 & 寫入 clone file 的速度會降一半
      • clone 來源
        • clone share (新版擋掉)
        • fast copy
        • 由 iscsi 觸發的 clone
        • dedup (可能會 clone 多次) ⇒ 可以擋掉 SSD Volume 上建 Cache 不給開 pin share
      • 另外若檔案只是 copy-on-write, 雖然寫入時會 drop extent, 但不會受影響
    • WIP CKYa 再研究放 drop extent 或 commit transation 比較好
• clone share 或 snapshot restore 就不支援，可能會有誤判特定 share 的情況 — 因為判斷 shared backref 成本太高

方向

• volume 新增下面選項
  • clone share 選項
    • 升級上來可直接判斷出來
      • 要和 user 說明為何是 enable 且不能關閉
  • UI 要說明 / alert 和 pin cache 互斥，開啟後就不能關閉 (因為不支援掃描)
• 舊 volume
  • 行為
    • if 任一個 share 有找不到 clone parent 的跡象 ⇒ 整個 volume 都不支援 pin cahce - (1)
    • else if 明確找出有些 share 是 clone share or snapshot restore 回來的 ⇒ 其它 share 還是可以開啟 pin acche ❓ - (2)
      • 都不支援可能比較容易懂
    • else 可以使用 pin cache
      • 即使有開 fast copy, 也可以用
  • 方案
    • 可快速判斷下面情況不支援 (預期比例不多)
    • 如果內部有 clone share 或 snapshot restore 的 share 就整個 volume 不支援 (1) (2)
      • 預期有這類動作的人不多，雖然下版掃描獨立 share 可能會好，但要和 user 有些支援有些不行也是太複雜了，還是建議以 volume 為單位
    • 否則可以使用
• 新 volume
  • 和 clone share 互斥, user 還是可以用 fast copy 和 snapshot restore
  • UI
    • 支援 clone share 選項，就不支援 pin cache
    • 如果 user 要執行 clone share 動作, 詢問他是否要開啟 volume clone share 選項，且說明將不支援 volume pin cache
• 只擋 clone share 的優點
  • 判斷快，不用掃描
  • 不用處理 fast copy UI