glusterfs 號稱 是不中斷業務擴容，意思是在後臺做擴容操作的時候不影響客戶端的訪問。原來一直沒有細看這一塊代碼，最近同事在afr層修改一些代碼的時候，遇到問題就是按glusterfs架構思路寫的代碼，把一些需要記錄的信息存放在inode 的ctx裏面，然而一做擴容或者其他需要改變graph 樹的時候就會出問題，發現設置在inode 裏面的ctx 沒了，父目錄也沒有做lookup操作，導致原有的處理邏輯亂了。
後來研究了一下客戶端收到擴容後的操作，簡單的說就是，服務端擴容後會給客戶端發送卷配置文件有改變，然後客戶端會重新向服務的getspec 獲取volfile，然後進行重新生成graph ，和舊的graph進行對比，如果graph結構沒變，就只reconfigure 就ok，這流程很簡單，如果比較 graph 結構變化，則要重新init graph ，意味着以後發下去的操作就要走新的graph樹流程了。但是原來client 緩存的fd table 和inode table 信息呢，這些緩存信息該怎麼處理呢？據代碼看 inode 是新申請了一個inodetable，fd table 會去同步原來的fd table ，由於 fd 關係着客戶端正在操作，讀寫文件啊，和readdir 啊，由於做了同步fd ，所以不會影響那些操作。然而由於全部廢掉了原來緩存的inode信息，再根據fuse 的特性，是肯定會影響客戶端的元數據操作的。例如在擴容前，cd 到一個目錄，擴容後在那目錄ls 原來的文件，會發現找不到那個目錄，由於他不會從/目錄開始發lookup，fuse以爲還緩存着這文件的父目錄，所以 這之間的矛盾會引起客戶端訪問文件元數據失敗。
值得思考的是 爲什麼沒有重新緩存node 呢？由於緩存太多的inode 的時候 重新發 lookup 時間長 影響客戶端阻塞。還是glusterfs 團隊沒考慮到 上面那點問題。