不同Raid Stripe大小對效能的影響

Posted on Leave a commentPosted in 邏輯層分析

什麼叫Stripe size

126427_orig
在raid card上有個stirpe size
單位為 64 Kbbytes = 128 Sectors

 

透過不同型態的RAID架構來評估Host-CPU的使用狀況….

基本上要指出到底從I/O request發出中斷使CPU被干涉多少次…

先放這張, 後續整理完後在貼上:

summary201012210102

從這張圖不難看出, Driver-based RAID體下,所有相關RAID計算都必須依靠Host CPU協助, 例如像是Stripping, 相關的計算都會引發對CPU的I/O請求觸發大量的I/O中斷操作. 看看SSD; Max I/O Read Test好了…

當條帶尺寸為8KB的時候, 這是一個較小的尺寸,在大量I/O的情況下, 是必要依靠Host-CPU多次操作8KB條帶切割/重組到不同的Disk, 尺寸很小的話, I/O需求量相對也會提高, 你可以看到8KB所觸發的中斷數量達到5萬多次, 反過來看看IOP-based RAID, 由於LSISAS2108透過built-in processor的這種協同式處理器, 像這類條帶操作都會被依賴到RAID chip上的built-in processor操作, 自然而然, Host CPU相對於I/O請求所觸發的中斷操作就明顯減少許多. 你可以注意到8KB的情況下, Driver-based RAID和IOP-based RAID明顯相差有10倍左右, 這意味著IOP-based RAID有更好的操作性能.

另外從Driver-based RAID看到, Response Time也有所不同, 對於I/O請求所需的回應時間, 大量I/O情況下, 我從們128KB來看, 最大Response Time相差了30ms左右, Avg. Response Time也有10ms之差異, 明顯可以看到IOP-based RAID這種Hardware RAID有更低的I/O延遲性.

CPU Effectivness指的是子I/O系統操作對於CPU所獲得的效益, 子I/O系統建構在kernel之下,子I/O系統包含了對各種裝置驅動程式(Device Driver), 裝置驅動程式的下層就是相關的控制器. 基本上這是可以算出來的:

CPU Effectiveness= IOPS / CPU Utilization

可以得到每單位使用量所能獲取的I/O效益, 這意味著大量IOPS情況下, CPU被過少的干涉(意味較低的CPU負載), 所能得到的效益就愈高, 你可以很清楚的看到Hardware RAID所獲得的效益遠遠高於Driver-based RAID. 雖然, ICH10R僅支持3Gb/s, 就算是6Gb/s也無法改變當前這樣的情況, 我懷疑支持6Gb/s可能會需要更多的I/O操作.

LSI不同RAID Stack測試(For LSISAS2008)

Posted on Leave a commentPosted in 邏輯層分析

此篇為LSI IR與IMR Stack之間的比較測試… 不過在此之前還是說明一些LSISAS2008相關的特徵 先看架構方塊圖…

924593_orig

 

可以看到有幾個部件, 大體上有一些重點:
1. 這是Software RAID, 硬凹的話, 沒意義的稱作”Hardware-assisted Software RAID”, 有沒有比較好聽 了一點呢?
2. Fusion MPT是一個I2O裝置, 主要拿來和Host協調.
3. 這顆有整合PPC440 533MHz IOP, 但是明確用途不知, 姑且稱作他會有副作用.
4. 2MB SRAM不是Cache喔, 請注意! 他只是單純的buffer用來存放相關的FIFO數據.
5. 那個32-bit Memory Bus是串接低速的OPB Bridge, 銜接例如FLASH, NVRAM這類等.
6. LSISAS2008的internal Bus應該是PLB4, 128-bit, crossbar架構, 頻寬其實很大.

再來看另一張比較:

intel_compare

這張左邊兩個當然是Intel自家開發的RAID Stack.. ERST2只會在它們自家的Server主板才看的到.. RST就應該不用說了吧..
這邊有一個重點特性, 就是IR3 RAID其實就是MegaRAID… 但是要點在於那個Persistent Controller Log… 這是一個與Event Log不同的地方..

他是Firmware Log, 這是極為有用的除錯Log…. 對應LSI就是TTY log…
MegaRAID支持這項機能…
這項功能相當有用… 相關的相容性問題或著錯誤問題可以由這Log來查…

另外IR的Software Stack支持MSI-X 當然我是指6Gb/s以後的產品…

3Gb/s產品全部都只能運行在Legacy Mode… 這是一個相當重要的特徵.. 雖然他不是甚麼新技術… IR和IMR的支持有所不同… IR提供大量的IRQ資源…

ir_irq_resource

IMR比較基本面…

mr_irq_resource由於在用途上有所不同因而有差異… LSISAS2008在IR下.. 不支持Stagger Spn-up 不支持Spin-down 相關的MAID機能通通都沒有.. 而在IMR下就是相反了…

下面就是不厚道的貼一部分測試.. 這邊是故意拿兩顆SAS HDD來測試… Seagate的7.2K SAS ES2… 直接就是RAID 0, 64K ioMeter不同測試設定: (QD深度從1個單位達到沒啥意義的256) >>Read(讀取)

io_meter_read_config

>Write(寫入)

io_meter_write_config-1

結果表(請點擊放大觀看):

io_meter_stack_compare

結果不好說…
不方便講可能的原因性, 不做亂猜測.. IMR的Response Time和Intterupts比IR高出不少…

下面這個HD Tach的情況比較怪異, IR連續測了4次左右, 結果一樣, 寫入很奇怪!..

>IMR情況

megaraid_hdtach

>IR情況

ir_hdtach

歡樂的ATTO當然是少不了的, 一律直接QD10…

>>IMR情況

megaraid_atto_qd10

>>IR情況

ir_atto_qd10

IR的情況也同樣比較詭異… AS SSD直接測SEQ. I/O:

IMR情況

megaraid_asssd

IR情況

 

ir_asssd

沒有差距太遠, IR我也是跑好幾次, 寫入似乎偏弱….. 最後的HDD Tune看看就好(其實沒甚麼參考性)…

IMR情況

ir_hdtune_write-1
ir_hdtune_read

IR情況

megaraid_hdtune_write

megaraid_hdtune_read

###關於LSISAS2008的補充: 對岸網友的詢問:

唉,有時候真的會弄不清楚這些 RAID 的種類,不知道這樣說對不對:
– 軟RAID,Driver based 的,就是不裝 driver 認不了的那種,例如 ICH, P67
– 軟+硬 RAID,可以支援 Firmware based RAID,不裝 driver 也能夠認得了,不過沒有自帶 IOP (?!),所以 RAID 5 靠 CPU? 例如 LSI SAS2008
– 全硬 RAID,有 IOP 可以算 RAID 5,不用 Host CPU 自己全部搞定,例如 LSISAS2108

“- 軟RAID,Driver based 的,就是不裝 driver 認不了的那種,例如 ICH, P67
– 軟+硬 RAID,可以支持 Firmware based RAID,不裝 driver 也能夠認得了” 都要裝driver(除非你打穿它(pass-through), 但是這樣不能用相關的RAID Utility做RAID)… 不管firmware-based RAID或著driver-based RAID也好..
他們全部都是Software RAID…
你可以把像ICH10或著P67這類稱為典型的ROMB RAID… 確實LSI可能在f/w封裝RAID算法..
不過這依然改變不了LSISAS2008是S/W RAID的事實…
像依照主板晶片採用的RAID..
例如Intel封裝的RST…
這類也可以稱為Firmware-based…
他依然有封入相關的RAID代碼在firmware… 不過通常是相關的啟動暫存器和相關的RAID BIOS代碼…
沒有所謂的軟+硬RAID…
稱其為H/W-assisted S/W RAID也只是針對LSI產品的特殊性…

“不過沒有自帶 IOP (?!),所以 RAID 5 靠 CPU? 例如 LSI SAS2008” 我想你指的IOP應該是指I/O Processor.. 不過LSISAS2008本身就是一種IOP… 我認為你應該要有更明確的稱呼….

Pure-H/W RAID的條件很簡單:
1. Hardware RAID Assist的存在
2. Internal MCU做為控制硬件Cache Memory的設計
3. Built-in Processor的存在
4. firmware stack的控制必須要將相關的I/O Processing轉移到RAID Controller上處理.. 可以看如下這張方塊圖…

lsisas1078_layout

ppc440spe

在記憶體控制器部分..
他銜接了XOR Engine..
你可以把XOR Engine稱為XOR加速器.. 這個是決定H/W RAID的最大關鍵… 根據這個設計與AMCC的PPC440spe幾乎長一個模樣..

從mov檔碎片分析談File Carving 原理

Posted on Leave a commentPosted in 邏輯層分析

前言:

一. Raw Recovery File 原理
當誤Ghost 純系統到儲存裝置,這時候Filesysem Index (如NTFS的MFT)損壞時,檔案系統檔案跟目錄名稱都無法辨識.
這時候只能用File Carving (Raw Recovery) ,從原始扇區hex的原始hex中“雕刻”出某些檔的“形狀”。
所以這狀況會需要從LBA 0跑到底.會很耗時間

File Carving技術就是基於檔案結構特徵和內容特點的,“架構”出檔案來。

什麼時候需要做File Carving?

例如遇到整個分區被誤格掉然後又有其他資料複蓋掉原本的分區的索引Data,用一般的救援軟體是無法回復的 也沒有原有的文件名稱。
此時就必須利用碎片搜索文件雕刻的方式慢慢的將想要的文件重組回來。
但重組回來也不見得是完整的檔案,必要時仍然必須將檔案處理過後才可使用。

但對影音檔而言,經常遇到即使在無覆蓋風險的情況下,恢復出來的視頻也是不完整的。原因在於傳統的資料恢復技術通過系統資訊進行的資料恢復不具有資料偵測能力,一旦資訊不完整,即使資料仍保留在數位設備中,也無法恢復。沒有了可依賴的系統資訊,我們唯一可以做的就是利用影音檔的結構特徵和內容特點,在“無差別”的資料區中偵測每個“未分配”的資料簇,判斷它們是不是我們期望得到的視頻碎片資料。在一個忽視系統資訊的環境中,如何偵測到每個影音檔碎片,並將它們有序銜接起來,並非本文研究的重點。這有許多工具可以做到。

本文要探討的是屬於資料重建中很難處理的視訊檔重建。而在過程當中最常碰到的問題就是MOV檔的重建,也是本文所要討論的重點。

二. 常用工具R-Studio是怎麼做的?

很多專業資料恢復公司使使用R-Studio這套軟體來做數據恢復。所以我們先來看看R-Studio怎麼做的。
實際上在救援的經驗當中發現R-Studio對於碎片搜索檔案重建的結果很不理想。

根據R-Studio的說明書中的Customizing File Type一節中,使用者可以自訂檔案的特徵值,請參考這是下載說明書看。
更詳細的說明書可至http://www.r-tt.com/zhhk/TechnicalSupport.shtml 下載。
我們以MP4檔案為例,檔案是 https://support.apple.com/en-us/HT201549 中的sample_mpeg4.mp4,下載後用Winhex打開。後可以看到MP4的特徵值。
8325402_orig

在檔頭的部分可以看到ftypmp42及mp42mp41。連續性的值(16進位)是
00 00 00 18 66 74 79 70 6D 70 34 32 00 00 00 01 6D 70 34 32 6D 70 34 31
所以這個mp4檔案的特徵值是可以寫成底下的方式以供R-Studio搜尋時使用。
\x00\x00\x00\x18ftypmp42\x00\x00\x00\x001mp42mp41

當然,MP4檔案的特徵值已直接被R-Studio所支援,使用者不需另外創立。當然R-Studio也有內建MOV的特徵值,但為什麼MOV檔案重建後的結果很不理想呢?我們推測是可能檔案重建時只有做Raw Data特徵值的比對,所以當特徵值某些部分被蓋掉後就有很大的機率判斷不出來或是誤判。為什麼會發生這樣的情況了,其實這跟MOV檔的特徵值有關。所以要做MOV檔案的檔案重建呢就必須先了解MOV檔的檔案結構。

三. MOV的特徵值
我們先來觀察一下正確的MOV長什麼樣子,下載 Apple官方的Sample mov
用Hex軟體打開後可以看到如下的檔案資訊。
4269934_orig
MOV檔案有幾個重要的Atom,Atom是QuickTime檔案的基本數據單位,每個Atom包含了大小跟類型以及之後的數據部分。Atom主要格式有wide、mdat、moov等。MOV檔在檔頭是由一些連續性的組塊(Chunk)所組合而成,每一個組塊是8個Byte:前面4個Byte代表組塊的大小,後面4個Byte代表組塊的類型。
現在跟大家介紹一下MOV檔頭是根據ISO制定而成,各有其意義。首先看到
offset 0~3分別是00_00_00_20。這個代表了這個box的大小總共有32個Byte。offset 4~7分別是66_74_79_70,指出這個box的類型是ftyp。
offset 8~B分別是71_74_20_20,指出這個類型的商標是qt(QuickTime)。
offset C~F分別是20_05_03_00,指出這個商標的主要版本。
offset 10~13分別是71_74_20_20,指出這個商標的相容的商標是qt(QuickTime)。
3617933_orig
看完了檔頭的box之後,我們來看wide atom,從這裡開始即完全要遵照Qucik Time File Format所定義的來做。
offset 20~23分別是00_00_00_08,代表了這個atom的大小總共有8個Byte。
offset24~27分別是66_74_79_70,指出這個atom的類型是wide。
在wide atom之後是另一個atom。wide atom 是表示後面是個擴展的atom,後面接的是mdat atom,也是資料主要的地方。
offset 28~2B分別是00_31_CA_34,代表了這個atom的大小總共有3263028個Byte。
offset2C~2F分別是6D_64_61_74,指出這個atom的類型是mdat。

那mdat atom的結尾在哪呢?來計算一下
0x27+0x31CA34=0x31CA5B
4008674_orig
mdat atom之後就是moov atom,moov atom由0x31CA5C開始。
offset 0x31CA5C ~0x31CA5F分別是00_00_52_C5,代表了這個atom的大小總共有21189個Byte。
offset 0x31CA60 ~0x31CA63分別是6D_6F_6F_76,,指出這個atom的類型是moov。
在這邊看到moov atom後面還有一個子結點mvhd atom。mvhd是moov的檔頭。
offset 0x31CA64 ~0x31CA67分別是00_00_00_6C,代表了這個atom的大小總共有108個Byte。
offset 0x31CA68 ~0x31CA6B分別是6D_76_68_64,,指出這個atom的類型是mvhd。
現在可以來驗證一下檔案長度是否正確,0x31CA5B+moov atom的長度
0x31CA5B+0x52C5=0x311D20。跟截圖的值是吻合的代表沒有算錯。

5856085_orig
由此可知,除了檔頭之外atom的資料也不能有錯誤,這樣才能正確的救回MOV檔案。但假如原始的資料被破壞太多的時候就會有資料不全的問題產生,導致救回的MOV檔案格式是錯的。
四. 案例分析
67072.mov是一個用R-Studio救回來的MOV檔,發現無法預覽畫面用VLC撥放器也無法撥放。用Winhex打開後觀察MOV的特徵值會發現重建後的資料是錯的,軟體將原本應該是檔案尾的moov資料寫到檔頭來了,造成撥放器無法撥放此檔案。
9927279_orig
將多餘的檔頭砍掉後即可發現已可播放幾秒鐘的畫面,此時檔案雖然已經可以預覽了但仍然不是正確的MOV檔,原因是少了後面的moov資訊。這時要將moov資料重建,重建moov資料後即可正常播放影像。

7652083_orig

5880577

為何檔案可以預覽這麼重要呢?因為當用Raw Data Recovery一次拉出來可能會有幾萬個檔案,這時確認是否是重要的資料的程序就很重要,利用此方法可以先預覽畫面確認檔案的重要性之後,再去維修檔案。