簡介MegaSR c100 RAID驅(qū)動是針對戴爾等服務(wù)器平臺中 c100 控制器的驅(qū)動程序包面向負(fù)責(zé)服務(wù)器存儲配置、系統(tǒng)重裝或硬件維護(hù)的IT運維人員。該驅(qū)動負(fù)責(zé)在操作系統(tǒng)中正確識別控制器并啟用RAID陣列的配置、讀寫與故障恢復(fù)功能適用于需要部署RAID 0/1/5等模式的業(yè)務(wù)服務(wù)器。壓縮包共40個文件包含inf安裝信息、sys核心驅(qū)動、oem簽名文件及cat安全目錄等覆蓋Windows Server 2003/2008等系統(tǒng)的x86與x64版本整體約1009KB安裝時可按系統(tǒng)位數(shù)對應(yīng)選用。資源已獲得186人學(xué)習(xí)瀏覽版本信息明確并附帶md5校驗文件便于驗證完整性。通過本驅(qū)動包運維人員可以在系統(tǒng)安裝或升級階段快速加載正確的控制器驅(qū)動避免因缺少驅(qū)動導(dǎo)致磁盤無法識別從而保障業(yè)務(wù)數(shù)據(jù)的安全性與存儲性能的穩(wěn)定發(fā)揮。1. 為什么服務(wù)器換上新盤后系統(tǒng)還是認(rèn)不出陣列前幾天幫某公司處理一臺老服務(wù)器RAID卡芯片是某代工廠貼牌的c100Linux內(nèi)核里對應(yīng)MegaSR驅(qū)動模塊?？蛻糇孕袚Q了兩塊硬盤在控制器BIOS里能看到虛擬磁盤已經(jīng)在重建但操作系統(tǒng)卻一直找不到根分區(qū)重啟后卡在“Loading megasr”后面黑屏。折騰到下午才定位到根因initramfs里根本沒有打包進(jìn)MegaSR驅(qū)動模塊雖然在內(nèi)核里但啟動早期根分區(qū)還沒掛載時它不會自動加載。這個場景不是個例——很多發(fā)行版默認(rèn)不把MegaSR放進(jìn)初始內(nèi)存盤一旦你換盤、重建陣列或升級內(nèi)核系統(tǒng)就會直接失聯(lián)。這篇文章就圍繞MegaSR c100 RAID驅(qū)動講清楚它是什么、怎么安裝、有哪些必調(diào)參數(shù)以及最常見的幾類翻車現(xiàn)場和修復(fù)辦法。給運維Linux物理機(jī)的人省點排查時間也幫準(zhǔn)備接手二手服務(wù)器的人判斷這塊卡值不值得用。2. MegaSR c100驅(qū)動到底是什么模塊加載邏輯與硬件識別2.1 驅(qū)動在Linux存儲棧中的位置從SCSI到塊層的映射Linux里訪問RAID卷不是直接讀控制器寄存器而是走一條完整的存儲棧。MegaSR驅(qū)動處在這條棧的最底層它通過PCI子系統(tǒng)找到RAID卡完成固件握手然后把控制器上每個邏輯卷注冊成一個SCSI設(shè)備再交給內(nèi)核的sd_mod驅(qū)動最終變成你熟悉的/dev/sda、/dev/sdb這類塊設(shè)備。也就是說MegaSR本質(zhì)上是一個SCSI HBA驅(qū)動不是直接的塊設(shè)備驅(qū)動。這個設(shè)計帶來一個很實際的后果你在系統(tǒng)里看到的設(shè)備名和你在RAID管理界面里看到的邏輯卷順序并不保證一致。MegaSR驅(qū)動枚舉卷時按照控制器固件返回的順序來創(chuàng)建SCSI設(shè)備而固件的返回順序可能與創(chuàng)建順序不同。比如你先建了RAID1卷再建了RAID5卷系統(tǒng)里sda可能是RAID5sdb反而是RAID1。這不是驅(qū)動Bug是固件對卷排序有自己的邏輯。c100代表的是控制器芯片的核心方案并不直接對應(yīng)某個具體板卡型號。很多OEM服務(wù)器廠商會把同一顆芯片貼成不同的產(chǎn)品型號甚至PCI Device ID都不一樣。這就解釋了為什么你從網(wǎng)上下載一個別人編譯好的MegaSR驅(qū)動加載時可能報“no such device”——因為模塊里內(nèi)置的PCI ID表沒有覆蓋你的板卡。所以判斷一塊卡到底用不用MegaSR驅(qū)動不能看品牌要看PCI vendor和device ID。驅(qū)動在初始化時會申請DMA緩沖區(qū)、設(shè)置中斷、讀取固件版本和BBU信息。如果這些步驟中任何一步失敗驅(qū)動會放棄注冊該控制器然后在dmesg里記錄一條錯誤。此時系統(tǒng)里就看不到任何RAID卷但控制器BIOS仍然可以正常管理陣列給人造成“硬件沒問題系統(tǒng)有問題”的錯覺。2.2 確認(rèn)控制器型號與模塊匹配的三條命令在動手之前先用三條命令確認(rèn)當(dāng)前機(jī)器到底認(rèn)不認(rèn)這塊卡以及該用哪個驅(qū)動。# 1. 查看PCI設(shè)備ID確認(rèn)RAID控制器型號 lspci -nn | grep -i raid輸出類似RAID bus controller [0104]: 某廠商設(shè)備 [vendor:device]。記下方括號里的vendor和device值MegaSR驅(qū)動源碼里的ID表會和它們匹配。# 2. 檢查MegaSR模塊是否已加載以及它支持的PCI ID modinfo megasr | grep -E alias|description如果modinfo顯示這個模塊不存在說明內(nèi)核里沒有編入MegaSR。如果存在alias一行會列出支持的PCI設(shè)備ID。把上一步查到的vendor:device拿來比對一致才說明模塊可用。# 3. 查找驅(qū)動文件是否在模塊目錄里 find /lib/modules/$(uname -r) -name *megasr*這里要特別小心megaraid_sas。有些系統(tǒng)同時具備megaraid_sas和megasr兩個模塊名字相似但支持的硬件并不一樣。c100屬于老方案時用MegaSR新一代SAS控制器啟用megaraid_sas。如果你同時加載兩者可能會發(fā)生驅(qū)動搶占同一個PCI設(shè)備輕則一個不生效重則在啟動階段直接崩潰。2.3 驅(qū)動初始化流程為什么有的盤變成sda有的變成sdbMegaSR驅(qū)動的初始化大致分四步PCI探測、固件握手、邏輯卷枚舉、塊設(shè)備注冊。PCI探測階段驅(qū)動遍歷總線上匹配的PCI設(shè)備為每個控制器分配IO資源、設(shè)置DMA掩碼和中斷。固件握手階段驅(qū)動發(fā)命令給控制器固件獲取控制器類型、緩存策略、BBU狀態(tài)等。邏輯卷枚舉階段驅(qū)動通過控制器的內(nèi)部命令查詢每個卷的RAID級別、容量、條帶大小和狀態(tài)并為每個卷創(chuàng)建SCSI設(shè)備。最后一步sd_mod接管每個SCSI設(shè)備向核心注冊塊設(shè)備。這個流程中邏輯卷枚舉的階段最容易出問題。如果某個卷正在做一致性檢查或者介質(zhì)掃描還沒完成驅(qū)動可能會等待該卷的狀態(tài)穩(wěn)定后再枚舉下一個卷。結(jié)果就是系統(tǒng)啟動時在驅(qū)動初始化處停留很長時間看起來像死機(jī)。你可以在內(nèi)核啟動參數(shù)里加loglevel7觀察驅(qū)動打印的枚舉日志看它卡在哪個卷上。還有一個常見現(xiàn)象是啟動后設(shè)備名稱變化。比如最近一次維護(hù)后業(yè)務(wù)腳本里寫的/dev/sda突然變成了/dev/sdb導(dǎo)致掛載失敗。原因是MegaSR驅(qū)動對卷的掃描順序受PCI總線掃描順序影響而PCI總線掃描順序可能因為插槽編號、BIOS設(shè)置而改變。解決方法是不要在腳本里用sda這種順序名改用/dev/disk/by-id/下的wwn或UUID。3. 從零裝上MegaSR c100驅(qū)動安裝包、initramfs與系統(tǒng)盤三板斧3.1 編譯安裝前的檢查內(nèi)核源碼、工具鏈與固件如果沒有現(xiàn)成內(nèi)核模塊你需要自己編譯。第一步不是急著make而是確認(rèn)當(dāng)前運行內(nèi)核和頭文件是否匹配。很多人在Ubuntu上執(zhí)行apt install linux-headers-$(uname -r)后直接編譯結(jié)果編出來的模塊加載時提示“version magic mismatch”。原因可能是內(nèi)核頭文件里帶著ABI版本信息而實際運行內(nèi)核帶的是另一套配置。對MegaSR這種老驅(qū)動模塊版本不一致是最常見的坑。我的一般做法是先查看uname -r ls -ld /usr/src/linux-headers-$(uname -r)確認(rèn)頭文件目錄存在并且目錄內(nèi)的Module.symvers和Makefile不是空的。如果內(nèi)核頭文件來自發(fā)行版?zhèn)}庫通常沒問題。如果是從內(nèi)核源碼手動編譯的需要先進(jìn)入源碼目錄執(zhí)行make modules_prepare。編譯MegaSR模塊時需要工具鏈和依賴包。在Debian系上準(zhǔn)備編譯環(huán)境apt install build-essential bc dwarves flex bison libelf-dev然后進(jìn)入驅(qū)動源碼目錄。對于MegaSR這種在內(nèi)核源碼樹里的驅(qū)動你也可以單獨編譯cd /usr/src/linux-headers-$(uname -r) make Mdrivers/scsi/megasr modules但這里有個隱藏依賴drivers/scsi/megasr/Makefile里可能引用頂層目錄的頭文件單獨編譯時容易缺少生成的頭文件。所以更穩(wěn)妥的是直接把MegaSR編進(jìn)內(nèi)核再重新編譯整個內(nèi)核。很多老運維嫌慢但MegaSR源碼已經(jīng)凍結(jié)多年直接進(jìn)內(nèi)核最省心。編譯完成后模塊文件一般是megasr.ko。手動拷貝到模塊目錄cp drivers/scsi/megasr/megasr.ko /lib/modules/$(uname -r)/kernel/drivers/scsi/ depmod -a注意如果目標(biāo)系統(tǒng)的/lib/modules權(quán)限不足需要sudo?？截愅瓿珊髆odprobe megasr能加載才算成功。3.2 重建initramfs讓驅(qū)動在根分區(qū)掛載前生效內(nèi)核模塊放進(jìn)/lib/modules只是第一步。系統(tǒng)啟動時根文件系統(tǒng)還沒掛載內(nèi)核先加載initramfs。initramfs里包含了磁盤驅(qū)動、文件系統(tǒng)驅(qū)動和一組啟動腳本它負(fù)責(zé)在內(nèi)存中把必要的驅(qū)動模塊按順序加載識別出根分區(qū)所在設(shè)備然后才掛載根分區(qū)。如果MegaSR驅(qū)動不在initramfs里啟動流程就斷了。所以安裝模塊后必須重建initramfs。Debian/Ubuntu的常用命令depmod -a update-initramfs -u -k $(uname -r)CentOS/RHEL 7用dracutdracut --force --regenerate-all如果你使用的是定制內(nèi)核并且initramfs工具檢測不到當(dāng)前內(nèi)核可以手動指定內(nèi)核版本dracut --force /boot/initramfs-$(uname -r).img $(uname -r)重建之后確認(rèn)initramfs里確實包含megasrlsinitramfs /boot/initrd.img-$(uname -r) | grep megasr # 或者 dracut 系的系統(tǒng) lsinitrd /boot/initramfs-$(uname -r).img | grep megasr有些發(fā)行版默認(rèn)不會把所有驅(qū)動都納入initramfs只在模塊依賴列表里出現(xiàn)。MegaSR因為老可能被排除。這時需要手動把模塊名加到initramfs的加載列表。Debian系在/etc/initramfs-tools/modules文件里加一行megasr然后再次執(zhí)行update-initramfs -u。CentOS系在/etc/dracut.conf.d/megasr.conf里寫add_drivers megasr 再執(zhí)行dracut --force。這里有一個容易被忽略的細(xì)節(jié)initramfs會壓縮壓縮后一般只有幾十兆。但如果模塊依賴被遞歸拉入可能膨脹到幾百兆。重建完務(wù)必檢查/boot分區(qū)剩余空間df -h /boot3.3 老系統(tǒng)安裝路徑用U盤引導(dǎo)后chroot修復(fù)最常遇到的情況是系統(tǒng)已經(jīng)起不來了你沒法進(jìn)系統(tǒng)去執(zhí)行update-initramfs。這時需要一張Live U盤或者救援光盤在Live環(huán)境里掛載原系統(tǒng)的根分區(qū)然后chroot進(jìn)去修復(fù)。啟動到Live環(huán)境后先確認(rèn)RAID卷是否可見。如果Live內(nèi)核本身有MegaSR驅(qū)動lsblk里應(yīng)該能看到RAID卷。如果沒有你需要先加載Live環(huán)境里備好的驅(qū)動模塊insmod /path/to/megasr.ko然后查看設(shè)備lsblk ls -l /dev/sd*找到根分區(qū)后掛載它和必要的虛擬文件系統(tǒng)mount /dev/sdb2 /mnt mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys如果根分區(qū)是LVM可能還需要激活卷組vgscan vgchange -ay然后chrootchroot /mnt /bin/bash在chroot環(huán)境中先確認(rèn)內(nèi)核版本再修復(fù)模塊和initramfsuname -r mount -t proc proc /proc需要注意的是Live系統(tǒng)內(nèi)核版本往往比原系統(tǒng)新。在chroot里重建的initramfs生成的模塊依賴是基于原系統(tǒng)的庫文件和模塊目錄所以最后生成的initramfs適用于原系統(tǒng)這一點不用擔(dān)心。但如果原系統(tǒng)的模塊目錄被刪了你需要從原系統(tǒng)備份里恢復(fù)。修復(fù)完成后先退出chroot再卸載掛載分區(qū)重啟。這個流程我至少做過十幾次每次成功的關(guān)鍵是掛載虛擬文件系統(tǒng)時別漏掉/dev否則在chroot里運行update-initramfs會提示device節(jié)點缺失。4. MegaSR c100驅(qū)動四個必調(diào)參數(shù)重建、緩存、對齊與超時4.1 陣列重建速度與rebuild優(yōu)先級怎么設(shè)MegaSR控制器的重建速率由固件控制驅(qū)動本身不直接管理。但你在Linux里看到的IO卡頓往往和重建速率設(shè)得太高有關(guān)。重建進(jìn)程會持續(xù)產(chǎn)生大量讀寫請求如果重建速率設(shè)為100%控制器固件會把大部分命令隊列留給重建操作業(yè)務(wù)IO的延遲就會飆升。常見做法是使用管理工具調(diào)整。對c100這種老控制器舊版工具可能叫MegaCli新一點的命令是storcli。下面以storcli為例# 查看當(dāng)前重建速率 storcli /c0 show rebuildrate # 設(shè)置重建速率為60% storcli /c0 set rebuildrate60重建速率不是越大越好。業(yè)務(wù)高峰期建議把速率壓到3040凌晨維護(hù)窗口可以提高到80。如果控制器里有多組陣列同時重建建議將總速率限制在60以下否則命令隊列會被重建請求塞滿連狀態(tài)查詢命令都要等很久。這里要注意驅(qū)動層也有IO請求排隊機(jī)制即每個SCSI設(shè)備的/sys/block/sdX/device/queue_depth。重建IO和業(yè)務(wù)IO最終都進(jìn)入同一個控制器命令隊列所以這個值也需要配合。不要為了壓隊列深度而把queue_depth調(diào)到1那會讓陣列重建慢到無法接受一般保持在32以上。4.2 寫緩存開關(guān)與BBU電池狀態(tài)聯(lián)動MegaSR控制器支持寫緩存但寫緩存安全依賴BBU電池。如果電池失效或電量不足固件通常會自動把策略改為透寫防止突然掉電導(dǎo)致緩存數(shù)據(jù)丟失。問題在于驅(qū)動層看到的緩存模式可能沒有同步更新仍然顯示W(wǎng)riteBack這會造成數(shù)據(jù)不一致風(fēng)險。在Linux下查看RAID卷的寫緩存模式hdparm -W /dev/sda輸出中write-caching on代表開啟。但hdparm顯示的只是塊設(shè)備緩存策略不完全是控制器直寫/回寫的狀態(tài)。更準(zhǔn)確的辦法是看管理工具里的當(dāng)前緩存模式storcli /c0/v0 show all | grep -E Current|Default更換BBU電池后一定要重新確認(rèn)緩存策略。我見過某次更換電池后控制器自動把卷模式改為WriteThrough但系統(tǒng)里dmesg完全沒有提示業(yè)務(wù)側(cè)寫延遲突然升高到原來的三倍。后來用管理工具把卷改回WriteBack重啟后生效。如果你沒有BBU或者電池狀態(tài)是Failed建議強(qiáng)制把驅(qū)動對應(yīng)的SCSI設(shè)備緩存設(shè)為透寫避免固件策略異常。在支持dynamic cache type的設(shè)備上echo write through /sys/block/sda/device/scsi_disk/0:0:0:0/cache_type注意這個路徑里的數(shù)字是SCSI host、channel、target、lun的組合需要先查看/sys/block/sda/device/scsi_disk/下的目錄名。4.3 4K扇區(qū)盤的alignment_offset怎么算現(xiàn)代大容量機(jī)械盤和SSD普遍采用4K物理扇區(qū)而傳統(tǒng)RAID卷常常暴露512字節(jié)邏輯塊。MegaSR控制器在創(chuàng)建卷時如果條帶大小沒有和物理扇區(qū)對齊就會出現(xiàn)寫放大一個4K邏輯塊可能跨越兩個物理扇區(qū)每次讀改寫要多讀一個扇區(qū)。查看卷的對齊信息cat /sys/block/sda/alignment_offset cat /sys/block/sda/queue/logical_block_size cat /sys/block/sda/queue/physical_block_size如果alignment_offset是0說明設(shè)備起始位置對齊了如果非0分區(qū)時需要使用能感知對齊的工具。用parted創(chuàng)建GPT分區(qū)時它會自動計算最優(yōu)對齊parted /dev/sda mklabel gpt parted /dev/sda mkpart primary 0% 100% parted /dev/sda align-check optimal 1align-check optimal返回1 aligned才表示起始扇區(qū)正確。如果提示未對齊刪除分區(qū)使用以下方式強(qiáng)制按扇區(qū)對齊parted /dev/sda mkpart primary 2048s 100%2048扇區(qū)起始可以整除4K也滿足大多數(shù)RAID條帶大小。條帶大小如果是256KB則分區(qū)起始至少要是256KB的倍數(shù)也就是512個扇區(qū)的整數(shù)倍。MegaSR驅(qū)動暴露的條帶大小可以在管理工具里確認(rèn)也可以在/sys/block/sda/queue/optimal_io_size里看到如果值為0說明驅(qū)動沒有上報需要按實際RAID配置計算。4.4 命令超時值與熱插拔沖突的權(quán)衡SCSI設(shè)備有命令超時機(jī)制超時后內(nèi)核會觸發(fā)錯誤恢復(fù)。MegaSR控制器在特定場景下會出現(xiàn)單個命令長時間不返回典型的如硬盤介質(zhì)掃描、全局熱備構(gòu)建、大范圍重建。這時候如果命令超時內(nèi)核會報錯并可能把卷置為離線。默認(rèn)超時在30秒左右可通過如下方式查看和修改cat /sys/block/sda/device/timeout echo 180 /sys/block/sda/device/timeout超時值調(diào)大可以避免正常重建過程中誤報錯誤但你也要承擔(dān)控制器真正卡死時系統(tǒng)延遲感知的風(fēng)險。我建議業(yè)務(wù)服務(wù)器設(shè)置為120180秒測試環(huán)境可以設(shè)300秒。不能無限大否則控制器固件異常后IO請求可能掛起很久才被上層發(fā)現(xiàn)應(yīng)用層已經(jīng)堆積大量超時任務(wù)。熱插拔場景下超時值不宜太大。當(dāng)硬盤被拔出時驅(qū)動會在一定時間內(nèi)未收到回應(yīng)然后重發(fā)命令。如果超時太大盤符不會及時移除系統(tǒng)會一直認(rèn)為設(shè)備在線。配合MegaSR控制器熱插拔時最好把超時保持在60秒以內(nèi)這樣可以快速觸發(fā)SCSI錯誤處理流程重新掃描設(shè)備。如果你既需要熱插拔又需要重建建議分時段調(diào)整平時60秒維護(hù)窗口調(diào)大。5. 五起MegaSR c100驅(qū)動翻車實錄現(xiàn)象、根源與修復(fù)5.1 啟動卡在“Loading megasr”后黑屏某臺服務(wù)器重啟后屏幕上顯示“Loading megasr ...”然后長時間無響應(yīng)十幾分鐘后黑屏。強(qiáng)制斷電再啟動依然如此。用U盤引導(dǎo)進(jìn)入Live系統(tǒng)后加載模塊成功查看dmesg發(fā)現(xiàn)是固件握手階段報錯megasr: failed to acquire controller memory。后來發(fā)現(xiàn)是控制器上的DDR緩存松動重新插拔RAID卡后恢復(fù)正常。這類現(xiàn)象容易被誤判為驅(qū)動問題實際是硬件接觸不良。解決方法是先拔掉RAID卡清潔金手指重新插緊。如果故障依舊檢查控制器固件版本有些舊固件和某些型號DDR內(nèi)存兼容性不好。5.2 內(nèi)核小版本升級后RAID卷自動掛載失敗某次例行更新系統(tǒng)內(nèi)核從5.4.0升級到5.4.0-xx安全更新版重啟后系統(tǒng)直接進(jìn)入緊急模式。檢查journalctl發(fā)現(xiàn)設(shè)備/dev/sda1不存在。原因是新內(nèi)核的initramfs里沒有包含megasr模塊而舊內(nèi)核的initramfs有。發(fā)行版?zhèn)}庫在生成內(nèi)核包時可能只將當(dāng)前加載的模塊打包進(jìn)新的initramfs如果升級時系統(tǒng)未加載MegaSR它就被漏掉了。解決方法是進(jìn)入舊內(nèi)核手動重建新內(nèi)核的initramfs并確保/etc/initramfs-tools/modules里有megasr。這個坑在自動化更新工具上很容易出現(xiàn)建議升級內(nèi)核后先驗證lsinitramfs再重啟。5.3 IO錯誤但控制器狀態(tài)顯示Online數(shù)據(jù)庫服務(wù)器運行時報大量IO錯誤dmesg里刷megasr: SCSI command timeout但登錄管理工具看到卷的狀態(tài)是Online。起初以為盤有問題換了新盤也沒解決。后來發(fā)現(xiàn)是業(yè)務(wù)高峰期大量隨機(jī)寫導(dǎo)致控制器命令隊列溢出驅(qū)動在重試時超過超時時間。解決方法是降低應(yīng)用層的隊列深度同時把/sys/block/sda/device/timeout從30秒調(diào)整到120秒。另外控制器固件里如果開啟了controller cache dirty閾值偏高也會出現(xiàn)寫到一定程度后命令延遲陡增。這類問題屬于性能配置不當(dāng)不是硬件故障所以狀態(tài)顯示Online但I(xiàn)O側(cè)已經(jīng)異常。5.4 重啟后塊設(shè)備順序顛倒導(dǎo)致掛載錯亂一臺機(jī)器原來/dev/sda是RAID1根分區(qū)/dev/sdb是RAID5數(shù)據(jù)卷。某次維護(hù)重啟后系統(tǒng)變成/dev/sda是RAID5根分區(qū)掛載失敗。原因在于MegaSR驅(qū)動枚舉邏輯卷時順序取決于控制器固件的卷列表。固件版本升級后卷的順序發(fā)生了變化。排查過程很典型用Live系統(tǒng)啟動lsblk看到兩個卷都在但設(shè)備名和fstab里寫的對不上。解決方法是把所有掛載點改為UUID或/dev/disk/by-id。fstab里改成UUID后重啟恢復(fù)正常。這起案例提醒我們不要在任何腳本里硬寫sda這類設(shè)備名MegaSR驅(qū)動的枚舉順序沒有嚴(yán)格保證。5.5 休眠喚醒后陣列變成Degraded服務(wù)器支持S3休眠休眠前RAID1狀態(tài)正常喚醒后系統(tǒng)提示卷變成Degradeddmesg顯示一塊盤被標(biāo)記為failed。實際盤并沒有故障是休眠時硬盤供電被切斷喚醒后盤未在限定時間內(nèi)響應(yīng)固件握手命令控制器誤判離線。解決方法是在硬件層面關(guān)閉對供電敏感的節(jié)能特性同時升級RAID卡固件。軟件層面可以把SCSI設(shè)備的allow_restart設(shè)為生效echo 1 /sys/block/sda/device/allow_restart但這個參數(shù)只影響SCSI層重啟命令真正起作用的還是固件對熱插拔的保護(hù)邏輯。建議生產(chǎn)環(huán)境禁用S3休眠改用重啟。6. 進(jìn)階用官方管理命令聯(lián)動驅(qū)動并抓住性能驗證的三個關(guān)鍵指標(biāo)6.1 用storcli核對控制器狀態(tài)與驅(qū)動日志MegaSR驅(qū)動運行時除了dmesg里的內(nèi)核日志還可以用管理工具從固件側(cè)拿到事件記錄。我習(xí)慣在排查問題時同時打開兩個窗口一個看dmesg -w一個跑storcli /c0 show events。兩邊時間戳對照能判斷一個錯誤是驅(qū)動層先發(fā)現(xiàn)還是固件先記錄。比如上一節(jié)提到的休眠喚醒問題固件事件里會有phys diskin failed的記錄而驅(qū)動日志里只有超時重試。如果只看驅(qū)動日志很容易誤判為盤線纜故障。查看控制器整體狀態(tài)storcli /c0 show查看卷的當(dāng)前緩存模式和狀態(tài)storcli /c0/v0 show all | grep -E State|Cache如果系統(tǒng)里配置了很多卷可以用storcli /c0/vall show all。老控制器不識別storcli時用MegaCli64MegaCli64 -LDInfo -Lall -aALL兩條工具的底層原理一致都是通過內(nèi)核ioctl和控制器固件通信。注意MegaSR驅(qū)動和多路徑軟件同時存在時管理工具的顯示結(jié)果可能受多路徑影響的設(shè)備路徑干擾因此最好在驅(qū)動加載后、多路徑啟動前執(zhí)行查詢。6.2 驗證驅(qū)動性能的三個指標(biāo)隊列深度、延遲和吞吐量調(diào)完驅(qū)動參數(shù)后不能只看系統(tǒng)能啟動就認(rèn)為沒問題。我通常用一組固定命令驗證驅(qū)動在重負(fù)載下的穩(wěn)定性。首先用fio測隨機(jī)讀寫fio --namemegasr-test --filename/dev/sda --direct1 --rwrandwrite --bs4k \ --iodepth32 --size4G --numjobs4 --group_reporting --time_based --runtime60重點看三個指標(biāo)隊列深度實際保持在哪里、平均延遲有沒有持續(xù)增長、吞吐量是否波動劇烈。用iostat -x 1看avgqu-sz和%util。如果avgqu-sz持續(xù)大于設(shè)備報告的最大命令隊列深度說明IO堆積嚴(yán)重如果延遲曲線每隔幾秒出現(xiàn)一次尖峰則要先查控制器是否存在定期刷新緩存的操作。第二個指標(biāo)是順序讀吞吐量fio --namemegasr-seq --filename/dev/sda --direct1 --rwread --bs1M \ --iodepth16 --size8G --numjobs1 --group_reporting --time_based --runtime30這個測試能快速暴露條帶大小與塊大小不匹配的問題。如果吞吐量只有理論值的一半檢查/sys/block/sda/queue/optimal_io_size和/sys/block/sda/queue/max_sectors_kb不順時嘗試把隊列塊大小調(diào)大echo 512 /sys/block/sda/queue/max_sectors_kb第三個指標(biāo)是IOPS穩(wěn)定性。用fio的--rwrandread跑十分鐘記錄每分鐘的IOPS方差。如果方差超過20%建議檢查控制器背板供電或RAID卡散熱。溫度過高的控制卡會導(dǎo)致固件觸發(fā)降頻保護(hù)IOPS會周期性下降?？梢杂霉芾砉ぞ卟榭纯刂破鳒囟萻torcli /c0 show all | grep Temperature我的個人習(xí)慣是每次調(diào)完參數(shù)、升級固件、更換硬盤后都把這套測試跑一遍。確認(rèn)穩(wěn)定后再接入業(yè)務(wù)。MegaSR這類老驅(qū)動雖然穩(wěn)定但固件和盤之間的兼容性坑比新卡多提前測試能省掉后續(xù)半夜報警的麻煩。希望這些經(jīng)驗幫到你。本文還有配套的精品資源點擊獲取