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