看到 dmesg 里反复刷 end_request: i/o error 就该停手，这表明阵列卡已丢失对磁盘的控制权，此时任何读写操作（如 ls、df、fsck）都在向逻辑断联设备发请求，可能加剧控制器状态错乱。
看到 dmesg 里反复刷 end_request: I/O error 就该停手了
硬件阵列卡掉电后最典型的表征不是“硬盘不识别”，而是内核日志里持续出现 end_request: I/O error, dev sdb, sector XXXXX 或 buffer I/O error on device dm-0。这说明阵列卡已丢失对底层磁盘的控制权，但操作系统仍试图通过旧的设备路径发 IO——此时任何读写（包括 ls、df、fsck）都在往一个逻辑上“断联”的设备发请求，不仅得不到数据，还可能触发控制器内部状态错乱。
实操建议：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 立刻执行
dmesg -T | grep -i "error\|fail\|offline"，重点看时间戳集中在断电前后那一段； - 不要运行
smartctl -a /dev/sdb——如果设备已从阵列卡逻辑视图中消失，smartctl可能根本打不开设备，报No such device或卡住； - 用
lspci -vv -s $(lspci | grep -i raid | awk '{print $1}')查阵列卡当前状态，关注Kernel driver in use是否还是megaraid_sas（或对应驱动），若显示unused，基本确认驱动已卸载或卡已失效； - 切勿尝试
mdadm --assemble或vgscan——软件 RAID/LVM 工具依赖底层块设备可用，而此时设备节点可能还在，但实际已无响应。
megacli 或 storcli 连不上，先查供电和电池状态
阵列卡掉电后最常见的“假死”原因是缓存电池（BBU）失效或电源管理芯片锁死。很多卡在断电瞬间若 BBU 电量不足或固件异常，会直接进入保护模式：不响应命令、不刷新缓存、甚至拒绝重初始化。
实操建议：
- 物理检查：打开机箱，确认阵列卡供电线（通常是 4pin 或 8pin 大4口）是否松动；BBU 指示灯是否熄灭或常红；
- 重启前先拔掉阵列卡电源线 30 秒，再插回——这是绕过部分固件锁死的最有效软复位；
- 若使用 LSI/Broadcom 卡，优先尝试
storcli /c0 show（/c0是控制器 ID）；若报CLI Failed with status code: 0x10，大概率是卡未就绪，不是命令错； - 若
storcli不可用，且系统是较老型号（如 Dell PERC 6/i），换用megacli -AdpAllInfo -aALL，注意加-aALL而非-a0，避免因控制器编号识别偏差漏检。
阵列配置还在但挂载失败，lost+found 里的数字名文件就是线索
当阵列卡恢复通信、LVM 卷组或 ext4 分区能被识别，但挂载后目录为空或报 Input/output error，说明文件系统元数据（尤其是 inode 表和目录项）在掉电瞬间被写坏。ext4 的 journal 可能来不及刷完，导致部分目录项残留为未链接状态，自动归入 lost+found。
实操建议：
- 先以只读方式挂载：
mount -o ro,noload /dev/mapper/vg0-lv_data /mnt/recover，noload跳过 journal 重放，防止损坏扩大； - 进
/mnt/recover/lost+found，里面全是类似#123456的数字命名文件——这不是垃圾，是 ext4 找回的孤儿 inode； - 用
file /mnt/recover/lost+found/#123456判断类型（如 “data”, “SQLite 3.x database”）； - 若需还原原始路径，得结合
debugfs：debugfs -R "icheck 123456" /dev/mapper/vg0-lv_data查 block 号，再用debugfs -R "ncheck 123456"反查路径（但成功率取决于目录项损坏程度）； - 别指望
fsck.ext4 -y自动修复——它会把大量未链接 inode 清进lost+found，反而掩盖原始结构。
RAID 配置丢失时，mdadm --examine 和 dd 镜像必须同步做
硬件阵列卡掉电后若 BIOS/UEFI 中 RAID 配置彻底清空（表现为 lsblk 看不到 md 设备，/proc/mdstat 为空），说明卡的 NVRAM 中的元数据已损毁。此时不能靠卡自己重建，而要从每块物理盘的末尾扇区提取 RAID 元数据头（superblock）。
实操建议：
- 先对每块盘做只读镜像：
dd if=/dev/sdb of=/backup/sdb.img bs=4M conv=noerror,sync，noerror和sync是关键，跳过读取失败扇区并保持偏移对齐； - 对镜像文件跑
mdadm --examine /backup/sdb.img，对比各盘的Events :、Update Time :、Array Slot :，找时间最新、事件号最大的那组作为基准； - 若某盘
mdadm --examine报No md superblock detected，不代表没 RAID 头——可能是头在非默认位置，用hexdump -C -n 1024 /backup/sdb.img | grep -A2 -B2 "md"手动搜特征； - 组合成功后，用
mdadm --assemble --force --run /dev/md0 /dev/sdb /dev/sdc ...强制启动，--force绕过一致性校验，--run强制激活降级阵列； - 此过程风险极高：一旦选错盘序或元数据版本，
mdadm可能写坏 superblock。务必确保所有操作基于镜像，原始盘全程只读。
ro、noerror、--dry-run（如果支持），宁可慢，不可错。
