【排雷指南】SSD缓存盘故障移除后，存储空间重启无法自动挂载的修复记录
一、问题现象
-
SSD只读缓存盘故障，导致存储资源池变为只读；
-
移除SSD缓存配置后，每次重启都需要手动进入设置重新挂载存储空间；
-
更离谱的是：后续用新硬盘创建的、完全不涉及SSD缓存的存储空间，重启后同样掉线，需要手动恢复；
-
尝试官方修复工具，报错：修复失败，配置中未找到0_corig/segment1。
（感谢玉尺书生的指导，帖子地址：https://club.fnnas.com/forum.php?mod=viewthread&tid=58238）这个应该适合没有移除ssd缓存，且你的缓存没有坏掉，只是临时故障，重建ssd缓存的存储池元信息。
-
其实还有一点我不是很理解，刚坏的时候我重启存储池一直是锁定状态，重启后也没有提供恢复选项，但是很长时间没管它这次处理时居然可以手动挂载激活了。
二、环境背景
- 系统：飞牛OS（FnOS）
- 原配置：存储池1：机械盘组RAID + SSD只读缓存加速；存储池2：机械盘单盘+SSD只读缓存加速
- 故障后：初步判断SSD盘故障了，表现为文件格式未知，关机状态移除SSD缓存盘。
三、排查与诊断
SSH登录root后，执行基础诊断命令：
bash复制
vgs -v
pvs -a
lvs -a
这里我使用了kimi帮我分析，毕竟我对Linux系统不懂。
关键发现：
- 卷组（VG）状态为
wz-pn-（p = partial，部分缺失）；
- 存在
[unknown] 物理卷（PV），UUID指向已移除的SSD缓存盘；
- 逻辑卷（LV）状态为
NOT available；
- 系统日志反复提示
Couldn't find device with uuid xxx。
四、根因分析
问题的核心不是存储空间本身损坏，而是LVM卷组的元数据被污染了：
- SSD缓存盘故障时，LVM的cache pool和origin映射没有正常解除，SSD盘在卷组中的PV注册信息残留；
- 虽然界面执行了"移除缓存"（底层是
lvconvert --uncache），但卷组（VG）层面没有清理掉这个已不存在的PV；
- LVM安全机制：当卷组中存在缺失的PV时，默认禁止自动激活（
Attr中的 n标志），防止损坏数据。这就是为什么重启后必须手动挂载；
- 官方修复工具的设计局限：它预期找到
0_corig等缓存段来执行修复，但你的系统已经 uncache完毕，缓存段早已不存在，因此直接报 segment1错误。
五、解决方案（已验证有效）
步骤1：SSH登录并切换root
bash复制
sudo -i
步骤2：清理残留的[unknown]物理卷
分别对每个受影响的卷组执行（务必确认残留PV的PE全部为Free，即无数据）：
bash复制
vgreduce --removemissing --force 你的卷组名
执行后再次检查，确认 [unknown]设备消失，WARNING消除。
步骤3：重新激活卷组
bash复制
pvscan && vgscan
vgchange -ay
步骤4：重启验证
bash复制
reboot
重启后检查存储空间是否自动挂载，逻辑卷状态应为 -wi-ao---（a=active, o=open）。
六、排雷要点与教训
| 踩坑点 |
说明 |
| 移除SSD缓存≠清理干净 |
界面移除缓存只拆了逻辑映射，LVM卷组里的PV注册信息还在，必须手动 vgreduce清理 |
| 官方工具不是万能 |
报错 0_corig/segment1时，说明工具按"仍有缓存配置"设计，但你已 uncache，需手动处理 |
| 新盘也会中招 |
如果新硬盘存储空间创建在被污染的卷组内，会继承同样的挂载问题 |
| 确认安全再force |
执行 vgreduce --removemissing --force前，通过 vgdisplay -v确认缺失PV的 Alloc PE为0 |
七、安全提醒
- 操作前务必备份重要数据；
- 如果缺失PV上仍有已分配的PE（非Free），说明SSD缓存盘上可能有数据，切勿直接force移除，需先联系官方技术支持；
- 读写模式的SSD缓存切勿直接物理拔除，必须先通过界面安全移除。
结语
这个问题折腾了很久，官方工具无法覆盖"已uncache但PV残留"的边缘场景。希望这篇记录能帮到后来者，遇到同样报错时少走弯路。如果清理后仍无法自动挂载，建议检查卷组 Attr是否被标记为 n（no auto-activation），必要时通过 vgchange --setautoactivation y开启。
