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