本文翻譯自vdbench的使用手冊中的數據校驗章節，如有紕漏，還請不吝賜教。

vdbench源碼下載地址：https://www.oracle.com/downloads/server-storage/vdbench-source-downloads.html

?

數據校驗在性能測試的時候不應該被使用，處理器開銷可能影響性能測試的結果。

在我開始之前，我想問一個想了很多次的問題：“為什么我使用vdbench去檢查數據沖突？我也可以寫一個大文件，計算校驗和，然后重新讀這個文件并比較校驗和。”當然，你可以這樣做，但是這種方法真的足夠好嗎？你正在做的一切都是在檢查數據在順序傳輸時的沖突問題。但是對于隨機IO怎么辦呢？檢查不是也很重要嗎？如果你對同一個block寫了X次，然后你發現內容是正確的。難道這不意味著你可能丟了X-1次連續寫入而沒有注意到？你花了24小時去寫，然后重新讀一個某個塊已經是壞了的大文件？這個塊什么時候被寫？什么時候再次被讀？是的，你可以高興的說：我用了一個周末的時間去計算出了錯誤的校驗和。這樣說可能更有用：“我在某個block發現了某個錯誤，我也知道這個錯誤什么時候被寫入，什么時候被發現的”。這個錯誤的塊也可能來自錯誤的磁盤。

看data_errors= 獲取數據問題的信息。

數據校驗流程如下：每次對SD或者FSD的寫入操作將被記錄在一個內存表里。被寫入的block的每一個512字節的扇區包含8字節的LBA和一個字節的數據校驗key。當對同一個block進行進行寫入時這個key會從1增加到126。一旦到達126，它將被回滾至1。0是一個內部的值，表示某個塊還沒有被寫入。這個key方法被用于識別丟失的寫入。如果一個塊被寫入多次，但是都沒修改這個塊的內容，這是不可能發現是否丟了一次或者更多次寫。使用這個key方法，我們只有丟失126次對同一個塊的連續寫入才會發現不了。

一個block被寫入一次后，每次對這個block的讀操作都會進行數據校驗。寫入操作之前會有一個讀操作，以確定原始數據是正確的。使用-vr執行參數強制每次寫入之后都被立即讀。然后這并不能保證寫入的數據一定到達了物理磁盤驅動，數據也可能是從緩存中讀出來的。

注意：從vdbench50407開始，數據校驗key不再從1開始。這是一個很重要的改變，為什么？你執行一次測試，以key=1開始寫入一個block。這筆寫入丟失了。當你讀的時候，你發現是過去的數據內容，因此并不認為數據沖突。通過讓每個block的key都從一個隨機數開始，我們可以保證這樣的沖突可以被識別到。當然，在連續的測試中同一個block隨機生成同樣的key，這仍然有1/126的概率。但這還是比每次都從一個同樣的key開始更好一些。針對重復塊的重刪flipflop機制也從一個隨機的key開始，并且zhi有最后一個bit被翻轉。

Vdbench50407引入了Owner ID的概念。對于正常的數據校驗來說，這將是Master vdbench的進程ID；對于journaling，它是日志文件第一個被創建時master vdbench的進程id。Owner ID總是存儲在每個扇區的28-31字節的位置。當使用重刪的時候，它會存儲在每個重刪塊的第8-11字節的位置。Owner ID的內容將檢查其有效性。Owner ID 的檢查是非常有用的：我經常遇到針對同一存儲的兩個vdbench測試，互相踩了對方的數據。因為Owner ID已經在status.html中被報告了，找到誰覆蓋寫了你的存儲而導致的數據沖突應該會很容易。

因為data validation tables被保存在內存中，在vdbench終止后，或者系統宕機重后，數據校驗將變得不可用。為了繼續使用數據校驗，可以使用journal。

Journaling：能夠在vdbench或者系統掉電后進行數據校驗，每筆寫入都被記錄在日志文件中。每次更新后，日志文件會被同步的刷到磁盤。每次日志更新都會寫512字節到磁盤。每一個journal entry是8字節，因此，單個journal record包含63個journal entry和一個8字節的head。當一個journal record中最后一個journal record被寫入時，額外的512字節的全零數據將被追加寫到日志文件中，這可以讓vdbench追蹤日志文件的結尾。每一筆寫入的前后都會寫入一個journal entry。

注意：我遇到過一個場景：日志文件被維持的很好，但是日志文件所在的文件系統在系統掉電之后變得無效。我因此要求日志文件設備去規避這個問題。

因為每一個vdbench負載寫引發兩個同步的日志寫，journaling將影響vdbench的負載的吞吐/性能。極力推薦你去使用一個開啟了后寫緩存的磁盤存儲單元。這將把vdbench負載的性能影響最小化。為了在日志寫入時使用文件系統緩存，可以指定'-jn'或者‘-jrn’去防止強刷。這樣做將加速日志的寫入，但是在系統異常關機時這些日志可能丟掉。進一步推薦把日志寫入到一個可被稱為"safe"的磁盤。不要往一個你正在進行故障注入或者其它嚇人的事情的磁盤上寫入日志文件。使用不可靠的journal，數據校驗可能不工作。

在快照場景下如果你想使用journal，不要擔心在vdbench測試時你的操作系統或者存儲會掛掉。在這種情況下，before/after寫入時不是很有必要。指定"journal=maponly",vdbench將不再寫before/after記錄，但仍舊會從內存中拷貝數據校驗map到日志文件。再次說明：這僅僅對正常停止的vdbench才會有用。

開啟日志運行的vdbench開始的時候，將創建兩個文件：一個map備份文件(.map)，一個日志文件(.jnl)。在內存中的數據校驗表內容將會被寫到備份文件和日志文件(所有的key都是0)。更新的journal將不斷寫到日志文件的尾部(參考"journal=(max,nn)")。在系統出錯后，vdbench重新啟動， 日志恢復被請求，原始map從日志文件的開始被讀出，日志文件中的所有更新被應用到該map。一旦到達了日志文件的結尾，所有被標記“modified”的塊將被讀并且其內容是有效的。接著，內存中的map將寫到日志文件的開頭，然后寫入到map的備份文件。journal record將被立即被寫入到日志文件中map的后面。如果由于系統掉電，map寫入到日志文件失敗，備份文件仍舊包含包含從上次運行開始之后的原始map。如果在下次日志恢復的時候，發現日志文件中并不是所有的map都寫入完成，map將從備份文件中恢復，在不完整的map之后并且仍舊在日志文件中的journal entry將再次被用于日志更新。

在一次日志恢復之后，有一種情形需要特別注意。因為每一個寫操作都有一個before/after條目，但系統掉電時，可能發生after entry可能還沒有寫入。在這種情況下，請求中的塊是否包含了before/after數據是不清楚的。在這種情況下，那個block將被讀，被比較的數據可能由兩個值組成，新數據或者老數據。

提示：journal=ignore_pending 或者執行參數 ‘-jri’將忽略這些掛起的寫入。

提示：我認為任何在寫入過程中間被中斷的存儲設備都必須有足夠的冗余電源去完成當前正在被寫的512字節的寫入，或者忽略。這意味著，如果一個扇區包含了新數據和老數據，這可能導致數據沖突。

一旦日志恢復被完成，在map中被標識為至少寫入一次的所有塊都被順序讀并且檢查他們內容的有效性，除非指定"journal=skip_read_all"

一次測試正常終止時，數據校驗map被寫入到journal。這扮演著兩個目的：日志文件的結尾將被重置為map之后的位置，因此節省磁盤空間，并且這會避免重讀整個日志文件的需求，應用它在map的開始位置防止再做另一次日志恢復。

提示：由于正在寫入的所有數據的歷史都是在一個Vdbench中使用不同的數據傳輸大小逐塊維護的，因此執行有以下限制：不同的數據傳輸大小是被允許的，只要他們是彼此倍數。如果一個實例中，你使用了1k,4k,8k數據傳輸大小，數據校驗將使用1k作為數據校驗的塊大小，因此一個4k的塊占用4個小的數據校驗塊。

提示：當你對一個大容量的磁盤空間進行數據校驗測試的時候，第二次訪問一個隨機塊可能需要一段時間。這意味著相對短的運行時間可能看起來是成功的，然而事實上并沒有數據block被重新讀并進行數據校驗。因此從vdbench5.0開始，vdbench追蹤實際有多少塊被讀和校驗。如果運行結束的時候，已校驗的塊的數量為0，vdbench將中止。

例如：對于一個運行100 iops，8k塊小的1TB的LUN，讓每一個隨機塊至少訪問兩次，這將需要744小時或者31天。

提示：當運行數據校驗時，一個塊的重寫實現了一個預讀，我建議當你需要指定讀操作的百分比時，指定rdpct=0。特別是在剛開始測試的時候，這將阻止讀到還沒有寫入的塊，這并不能被比較，浪費寶貴的iops和帶寬。但這些運行時，你將看到讀百分比從0開始，但是一點vdbench開始寫以前已經寫入的block，讀百分比會慢慢爬到50%。

總結

以上是生活随笔為你收集整理的vdbench数据校验翻译的全部內容，希望文章能夠幫你解決所遇到的問題。

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