= Lustre's Load Balance Mechanism =
 * 利用虛擬機初步測試的結果發現 Lustre 檔案系統在'''寫入'''操作方面，本身就具有 load balance 的機制，[[BR]]
   在 OST 具有不同大小的情況下，MDS 會先指派 free space 較大的 OST 給予 client 寫入檔案。[[BR]]
   然而若 OST 全部具有同樣大小的情況，MDS 則會採用 round-robin 的機制，輪流分配 OST 給 client 端寫入檔案! [[BR]][[BR]]
 * 得到上面這個結論後的第一個反應就是，那麼 read 的 Load Balance 豈不是也已經作好了?[[BR]]
   一旦當初被寫入的檔案很平均地分布在各個 OST 中，那麼當 client 要讀取的時候，load 照理說也會自動被分散掉不是嗎?[[BR]][[BR]]
 * 關於這點必須要還再思考，並且構思接下來要實驗的方式!

 * 使用 lfs 指令可以指定 file stripe 的大小、以及欲使用的 OST 數目，這個對 Load Balance 將會有幫助!

 * Lustre 在處理 file stripe 上面有個缺點，就是無法自動判別 target OST 是否還有空間可以存放資料。譬如說，有四個不同大小的 OSTs ，其中最大的是40GB (假設是 OST01)，最小的是 5GB (假設是 OST04)，如果採用 file stripe 的方式將大檔案均勻分割再平均撒到四個OSTs中，這個情況下，OST04 一定會最先用完容量，一旦 OST04 的容量用完，那麼這個 client 就再也無法寫入任何檔案至所掛載的 Lustre 檔案系統中；可惜的是，此時其他的OST可能還有許多空間可以利用(光是OST01應該就還會有35GB的空間可以使用)。因此這是 lustre 在處理 File Stripe 時的一個重大缺點。用一句話來形容："針對容量差異越大的 OSTs，Lustre 就越無法有效率地使用它們"。

 * 相反地來說，若是針對OST大小差不多的情況來看的話，"lfs setstripe" 指令在處理大檔案這方面，的確提供了相當好的 Load Balance 機制。以 Grid 的概念來看的話，是不可能每個 OST 都差不多擁有相近的容量的；然而若是以 cluster 來看的話，OST 的大小是可以設定成差不多的。以目前的測試環境來看，比較像是 cluster 的環境，因為大多是相同容量的硬碟。以測試來說的話，這個問題可以暫時忽略。

 * 以 "lfs setstripe -c -1" 這個指令來看的話，若是可以修改它，讓它做到隨時自動偵測各個 OST 的大小，並且及時回報給 MDT，促使 MDT 不要再將寫入的任務分配到即將耗盡空間的 OST 中，這是一個可以嘗試的方向，這個貢獻看起來似乎是還滿有意義的。

 * 如果不考慮 File Stripe 的話，就沒有上述的困擾，上面都是針對 File Stripe 來討論，如果讀寫的檔案以小檔居多的話，實際上並不需要做 File Stripe 的動作，如此就沒有 OST 會浪費的問題，因為 Lustre 有內建機制可以自動將寫入的任務分配到剩餘空間(Free Spaces)較多的OST中。

=== 整理一下上面所描述的成一張表格： ===
||OST大小\欲存取的檔案大小 || 大檔案居多(need stripe files)||小檔案居多(no stripe needed)||
||OST的大小差異大 (類 Grid 的環境)||使用 lfs 指令，但有無法有效利用所有 OST 的重大缺點||使用 Lustre 內建的 weighted allocator 來自動尋找空間剩餘較多的OSTs||
||OST的大小差異小 (類 Cluster 的環境)||使用 lfs 指令即可完美達到 Load Balance 的目的||使用 Lustre 內建的 round-robin 機制來自動輪流將檔案寫入 OSTs 之中||

 * 眼尖的民眾可以發現一個有趣的結果就是："最差的就會拖累整體"。平行運算中只要有一個特別慢的，那麼很可能就會拖累整個工作進行的速度；而檔案系統也是如此，容量越小的越容易拖累大家。但是在檔案系統中，只要能解決 "lfs setstripe" 指令在 類-Grid環境中處理大檔案的重大缺點，就可以結決此問題。就像在平行運算中使用 task-pull 的方式是一樣的道理，簡單地說就是能力越強的，要做的事情就越多。檔案系統也是，容量越大的，它被寫入的機會應該也要越大才是。直到大的都用完了，再來用小的。