Please enable JavaScript.

Coggle requires JavaScript to display documents.

Hybrid Share (Usability (server inode conflict (type 1 同一台同 request 重送…

- - - - Part2
  - - - 需要研究一下怎麼判斷中國區域
        
        擋簡中語系
  - - - possible sol
        
        inode conflict response
      - example
        
        network failure
    - - example
        
        vdsm snap restore
        
        snap replication
      - possible sol
        
        pre-snap hook
    - - example
        
        SHA split brain
        
        migrate assistant
        
        vdsm clone
      - possible sol
        
        allocate server inode range 時紀錄 sn
  - - - 會建立大量 index
        會 read file content (meta data)
        會做 machine learning
  - - - 討論中
        
        因 Hybrid share 會 dedupe 無法支援
- - - - 主要是 Zero chunk 原因影響效能，剩 FS3017 待確認
        
        撞到 single channel 問題
    - - 影響還好，preview 不處理
    - - DS918+ Hardware 設計，兩個 SATA port 共用單 PCIe channel
  - - - CST 研究中
        預期 4月可能要要配合修改
        
        修改 protocol 以移除Changed Lock
        
        目前測試結果
        
        目前上傳速度卡在 swift 能力
  - - - disconnection 11ms
        
        每 60 秒的斷線機制是 server 防護機制
      - token expired issue 由 server 提供 API (fixed)
        
        Client 需修改 (done)
    - - done
  - - - 細部討論會有狀況，目前定案
        (1) 第一次 create 才有權限設定
        (2) remount 不跳權限設定
        
        Done
  - - - Directory Lock CST 處理中(done)
- - - - RD 確認過非 bug
  - - - 測試 pthread_aio
        
        Round(1) passed
        
        Round(2) passed
        
        討論是否使用 pthread_aio
        
        Preview，使用 5 秒 timeout
        目前階段使用 pthread_aio， samba 更動會太大
  - - - Preview 先不支援 VDSM
  - - - proposal
    - - proposal
        
        以此方式實作
  - - - wireshark (ongoing)
        
        round(1) 使用 wireshare 抓封包做不出來
        
        round(2)
        
        發現是 Snoopy 問題
        改抓 snoopy 封包
        
        暫時做不出來
  - - - (a) kernel lock framework
        
        副作用: C2-event 會卡太久，有可能會塞爆
        
        技術上較難實作，不夠簡單
        
        改 lock 架構，其他不用改
      - (b) Tag-based
        
        副作用: C2-event 會卡太久，有可能會塞爆
        
        技術上較簡單
        
        小改等待方法，其他不用改
        
        存兩份 hashTag & DB
        review systemcall 折損
        
        一旦實作，相容性大改
    - - (c) 保留 inode-DB
        
        使用 LRU-DB 方法
        
        需要記得最後使用的 File
        剛開始使用可能會拖慢
        
        存法不用變
        
        透過 action 即時抓取
        
        每一次平均慢
        
        存法不用變
      - (d) 拔掉 DB 中 timeStamp
        
        更改 timeStamp 存法到 kernel space
        review systemcall 效能折損
        
        timeStamp 存取速度快
        
        需要評估 lock 裡會做多少事 ?
        
        不會做太多事 => OK
        
        最終採用方案
      - 有沒有可能 inode-to-path 卡很久 ?
        
        不會卡住主流程
  - - - Version 一併處理 conflict (Solved)
  - - - 訂案先長度先訂 (4096-512)
- - - - Zero 不上傳的機制
        
        改為 Zero 還是上傳
        避免 chunk is not existing
  - - - Ongoing
        
        SSD-Passed
        
        HDD-passed
    - - Single share passed
    - - Actiond is idle.
    - - Todo
    - - Passed
  - - - 會造成 syslog-ng CPU 使用率過高的問題已經解在 DSM#31284 了。
    - - 5/18 號跑 => 5/22 跑
        
        還是來不及，預計除了 rename 外的先跑
        
        5/26 撞到兩個 drive 問題