Linux內核2.6.32中的Raid5.h一上來就是150多行的注釋！看起來好辛苦，簡單翻譯一份留在這里，翻譯不對的地方希望大家指出~

?

每個條紋都包含一個buffer，每個buffer和每個磁盤對應。每個buffer都包括一些列的狀態(tài)，存儲在flags字段中。這些狀態(tài)之間的切換“幾乎”都是異步的，并且在一個“每條紋”的自旋鎖中進行。一些非常特殊的標志位改變可以在bi_end_io中進行，這些改變不會由自旋鎖保護。

兩個標志位R5_UPTODATE和R5_LOCKED指出四種不同的狀態(tài)：
State Empty == !UPTODATE, !LOCK
?????? 內存（buffer）中沒有數(shù)據(jù)，而且也沒有活躍的請求
State Want == !UPTODATE, LOCK
?????? 這個塊上提交有讀請求
State Dirty == UPTODATE, LOCK
?????? 內存中有數(shù)據(jù)，正在被寫入磁盤
State Clean == UPTODATE, !LOCK
?????? 內存中有數(shù)據(jù)，并且和磁盤上的數(shù)據(jù)是同步的
狀態(tài)轉換可能：
?*? Empty -> Want?? - 讀或者寫（寫操作需要讀舊數(shù)據(jù)用于更新校驗）
?*? Empty -> Dirty? - 計算校驗數(shù)據(jù)（sync或者重構寫）
?*? Empty -> Clean? - 一個失效的設備上恢復出來的數(shù)據(jù)
?*? Want? -> Empty? - 讀失敗
?*? Want? -> Clean? - 讀請求成功完成
?*? Dirty -> Clean? - 寫請求成功完成
?*? Dirty -> Clean? - 寫失敗
?*? Clean -> Dirty? - 計算校驗數(shù)據(jù)（sync或者重構、讀改寫）

Want->Empty, Want->Clean, Dirty->Clean的過程都發(fā)生在b_end_io的中斷中。每次都要在釋放鎖標記位之前設置Uptodate位。
只剩下一種多狀態(tài)轉換可能：Want->Dirty->Clean。這種轉換是安全的，因為，試想一個標記為Clean的buffer如果實際上是dirty的，最壞情況便是推遲了一些動作，條紋會在轉換完成的時候注意到并且被重新調度。

上述狀態(tài)并未包括一種可能性，即如果一個設備失效，同時有一個spare的設備正在重構。我們無法區(qū)分一個由計算校驗而產(chǎn)生的clean的塊還是一個成功寫入spare設備的塊（或者是resync進行中的校驗）。為了區(qū)分這兩種情況，條紋中的STRIPE_INSYNC為用以指明。當一個寫操作是面向spare設備，或者沒有spare設備的時候面向校驗盤，該位將被置位。一個sync請求將復位該位，當我們發(fā)現(xiàn)（置位并且）沒有任何buffer鎖住的時候，就知道sync完成了。

md設備的buffer通過make_request是依附在合適的條紋中，這些條紋在兩個b_reqnext鏈表之一。bh_read是讀請求鏈表，bh_write是寫請求鏈表。一個buffer應該是不可能同時存在于兩個鏈表中，但是我們無法保證這一點，因此需要做更多的許可。

如果一個buffer對應的cache buffer標記為Uptodate的并且在讀鏈表中，數(shù)據(jù)將拷貝到讀緩沖區(qū)，并且調用自己的b_end_io例程。這種情況僅僅發(fā)生在buffer剛剛成功讀取時候的end_request例程中。end_request需要將buffer從列表中移除，然后設置buffer的Uptodate位。其他線程僅僅在他們第一次檢測Uptodate被設置的時候這么做，一旦檢測完成，就將buffer從讀隊列中移除。

當一個寫鏈表中的buffer進行寫提交時候，將被拷貝到cache buffer中，這時將標記為dirty，并且移至第三個列表，written列表（bh_written）。一旦校驗快和cache buffer都被成功寫入磁盤，written列表中的buffer們將隨b_end_io返回。

寫列表和讀列表都以fifo的方式工作。讀列表由device_lock保護。write和written列表由條紋鎖保護。device_lock將在條紋塊持有的時候聲明，僅僅用于人工修改列表，并且持有很短的時間。可以從中斷中聲明。

stripe cache中的條紋可以在兩個列表中的一個里（也可以一個都不在）。“非活動列表”包括了當前沒有被任何請求使用的列表，可以自由的由其他條紋使用。“處理列表”包括了需要按某種方法處理的條紋。這些列表都是fifo的隊列。每個條紋也都（可能的）連接到一個哈希桶中，因此可以由扇區(qū)號索引到。條紋沒有被哈希的，一定是在非活動列表中，并且一般都是在前頭。所有的條紋都是以這種方式開始自己的生存期。

非活動列表、處理列表和哈希桶列表都由device_lock保護
---非活動列表中的條紋永遠不會獲得其條紋鎖
---條紋都有引用計數(shù)，如果count==0，則必定在某個列表中
---如果一個條紋必須需要處理，STRIPE_HANDLE置位
---當引用計數(shù)到達0，如果STRIPE_HANDLE沒有置位，該條紋放在非活動列表中，否則放在處理列表中

結合STRIPE_HANDLE僅僅當條紋具有一個非0的引用計數(shù)的情況下才能被復位，這意味著如果引用計數(shù)到達0并且STRIPE_HANDLE被置位，該條紋一定在處理列表中，如果STRIPE_HANDLE復位，該條紋一定在非活動列表中。

可能的轉換包括：
---沒有哈希/非活躍條紋---->激活（get_active_stripe()）
?? ++設備上鎖--檢驗哈希--unlink條紋--cnt++--clean條紋--哈希條紋--設備解鎖
---哈希（很可能是活躍）的條紋--->激活（get_active_stripe()）
?? ++設備上鎖--檢驗哈希--if（！cnt++）unlink條紋--設備解鎖
---將一個請求加到一個活躍條紋頭上（add_stripe_bh()）
?? ++設備上鎖--附加buffer--設備解鎖
---處理一個條紋（handle_stripe()）
?? ++條文上鎖--清STRIPE_HANDLE位--（設備上鎖--檢測buffers--設備解鎖--）--改變狀態(tài)--記錄需要的io/ops--條紋解鎖--調度io/ops
---釋放一個活躍的條紋（release_stripe()）
?? ++設備上鎖--if(!--cnt){根據(jù)STRIPE_HANDLE將條紋放回處理列表或者非活躍列表}--設備解鎖

引用計數(shù)記錄了激活了這個條紋的線程數(shù)+正在處理這個條紋的raid5d+cache buffer上的活躍請求數(shù)目，如果條紋正在進行條紋操作，那么再加1.

對條紋的操作在條紋鎖的外面進行，主要包括：
---在stripe cache和用戶應用緩沖之間拷貝數(shù)據(jù)
---為了減少一次磁盤訪問進行的塊（重構）計算，或者恢復一個丟失的塊
---寫操作中的更新校驗
---檢測校驗是否正確
---運行到磁盤的I/O操作
這些操作都由raid5_run_ops進行，這個函數(shù)使用了async_tx相關api，使用專用的硬件以（可選的）減少操作負載。當請求一個操作時候，handle_stripe設置操作的pending位并且計數(shù)加一。每當計數(shù)為非0的時候，raid5_run_ops運行。
為了避免一些操作被請求而另一些操作正在進行的情況，操作之間要服從一些嚴格的依賴：
（1）因為校驗檢查操作破壞了校驗塊的緩存中版本，所以必須防止檢查進程進行中的依賴校驗的操作，比如寫操作和計算塊（即恢復塊）操作。一些dma機器可以在不破壞校驗塊的前提下進行檢查操作，這時校驗塊將被重新標記為實時（假設檢查操作成功）并且不從磁盤中重新讀取。
（2）當一個寫請求到來時，要立即鎖住相關的塊，標記這些塊為過期。這造成了新的讀請求被攔截，并且?guī)砹诵ｒ灆z查和塊的計算操作。
（3）一旦有塊計算請求，handle_stripe將這些塊視作已經(jīng)實時有效。raid5_run_ops保證任何獨立于塊計算結果的操作都在塊計算完成之后被初始化。

操作狀態(tài) - sh->lock之外能看到的內部狀態(tài)
一般的，_idle表示什么都沒有進行中，_run表示一個數(shù)據(jù)操作正在進行，_result表示數(shù)據(jù)操作的結果是穩(wěn)定的（即運算完了），并且可以受到（別的操作影響）。對于像biofill這樣的簡單操作和只有一個_idle和_run狀態(tài)的計算，都用sh->state標志位表示（STRIPE_BIOFILL_RUN和STRIPE_COMPUTE_RUN）。

?

轉載于:https://blog.51cto.com/luckybins/666430

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Raid5.h注释翻译的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。