您好，参考

排查操作顺序

1. onestor‑tool cache status，确认哪个 slot 状态为 error/fault；看缓存盘是否mounted、OSD 绑定是否正常。
2. 看/var/log/onestor/cache.log，确认是元数据损坏还是分区残留。
3. 若存在残留缓存 dm 设备：dmsetup remove <设备名>清理残留分区，不要直接删磁盘分区表H3C。
4. 轻量修复：解绑异常 slot 缓存，重新绑定；严重情况：移除该 slot 闪存加速，重新创建缓存。
5. 业务风险提示：解绑 / 重建缓存会短暂影响该节点 OSD 读性能，不要业务高峰操作。

Workspace/CloudOS slot 缓存异常排查（闪存加速 SSD 缓存，eall/sall/v4 show all 硬件、逻辑均显示正常，但平台报 slot 缓存异常）

现象说明：eall看物理盘硬件状态正常；sall、v4 show all看存储池逻辑盘、OSD 状态正常；但是告警报某节点 slot 缓存异常。 该告警属于闪存加速（读缓存）层状态异常，不是底层 OSD 磁盘硬件故障，eall/sall/v4 show all不会输出缓存层内部状态H3C。

一、查看 slot 缓存（闪存加速）状态命令（登录异常节点的 Linux 后台 root）

注意：eall/sall是看底层磁盘、OSD；缓存加速层有独立命令。

1. 查看集群所有 slot 缓存概要

输出会列出每个节点、每个 slot 缓存盘的 State：ok / abnormal / offline / broken，异常节点这里会直接显示abnormal。

2. 针对故障节点，查看该节点详细缓存信息

可以看到 slot 编号、SSD 设备路径、缓存分区、状态、模式（read‑cache）、命中率、脏块计数。

3. 查看缓存对应的物理设备映射

查看 slot 与 /dev/sdX 设备对应关系，确认告警的 slot 对应的 SSD 盘。

4. 查看缓存相关告警事件

定位缓存异常的原始事件，看是：分区识别失败、元数据损坏、缓存分区残留、IO 报错、缓存未挂载。

5. 系统底层确认磁盘分区（root）

确认 SSD 缓存盘识别正常，看是否存在重复缓存分区残留（常见故障点：删除节点后残留旧缓存分区，重新加入集群导致 slot 状态异常）H3C。

二、常见根因（eall/sall 全部正常但报 slot 缓存异常）

1. SSD 硬件本身 OK，但缓存元数据损坏：磁盘硬件检测 eall 正常，但是缓存分区内部元数据异常，v4 cache 识别为 abnormal。
2. 缓存分区残留：曾经删除过存储节点，SSD 盘上遗留旧缓存分区；节点重新加入集群，新旧缓存分区冲突，报 slot 缓存异常，底层磁盘逻辑 OSD 全部正常H3C。
3. 缓存分区未自动挂载：系统启动阶段缓存分区挂载失败，但 OSD 数据盘正常上线，sall看不到缓存层故障。
4. 缓存盘 IO 瞬时报错，元数据标记异常；磁盘后续 IO 恢复，硬件检测 eall 恢复 ok，告警残留未自动清除。

三、处理步骤（按顺序操作，重要：操作前先做集群备份，业务低峰操作）

⚠️闪存读缓存可以直接移除，不会丢失业务数据；只是性能下降，业务虚拟机不会损坏。

1. 先确认告警对应的 slot 编号、节点、SSD 设备，通过 v4 cache show获取。
2. 如果是残留旧缓存分区：

如果 dmsetup remove 失败，重启该 CVK 节点后再执行清理H3C。

3. 重置异常 slot 缓存：

执行完成后执行v4 cache show确认 state 变为 ok，查看平台告警是否清除。

4. 如果重置 slot 缓存失败，说明缓存元数据彻底损坏：

• 将该 slot 缓存盘从闪存加速中剔除（业务继续运行，只是失去 SSD 读加速）；
• 格式化 SSD 缓存盘，再重新 add‑slot 加入缓存。

警告：不要直接格式化正在正常工作的缓存 slot，只会对异常 slot 执行格式化。

四、日志收集，需要提交 400 时抓取

五、补充说明

1. eall：只检测物理磁盘硬件状态（电源、介质错误、坏块硬件状态），不检测闪存缓存元数据逻辑状态，硬件没问题就返回正常。
2. sall / v4 show all：只看 OSD、存储池、数据分片逻辑，不包含 cache 闪存加速层状态。

所以会出现硬件、OSD 全部正常，但平台报 slot 缓存异常现象。