针对Workspace节点Slot缓存异常，可以通过管理界面的一键巡检或后台命令行两种方式来查看具体状态。

方案一：通过管理界面一键巡检（推荐优先尝试）

这是最直接、风险最低的排查方式，平台会自动进行诊断。

1. 登录H3C Workspace/UIS管理平台。

2. 点击页面右上角的 “一键巡检” 按钮。

3. 巡检完成后，进入 “告警”或 “故障” 页面。

4. 查看是否有 “一键修复” 选项，并尝试让平台自动修复。
   此方法尤其适合物理盘正常、但平台有逻辑误报的场景。

 方案二：后台命令行方式

如果界面无法解决问题，可以登录出现异常的节点后台，使用命令行进行精细排查。

1. 基础状态确认
先确认节点本身是否在线且健康。

第一条命令查看节点是否注册且状态为Ready，第二条查看节点整体健康度。

2. 查询Slot缓存状态（核心命令）

• 查看实时运行状态：

  bash

  workspace slot cache show --node <节点ID>

  这条命令会显示缓存使用率、命中/丢弃计数、缓存池容量等关键信息。可加--refresh 5参数每5秒刷新一次。

• 查看详细占用明细：

  bash

  workspace slot cache detail --node <节点ID>

  可按slot号展示已用/剩余缓存及异常标记。

• 查看历史统计趋势：

  bash

  workspace slot cache stat --node <节点ID>

  用于定位异常发生的时间点，排查是否存在缓存溢出或泄漏。

注意：以上命令适用于Workspace V2.0及以上版本。若版本较低，可尝试在命令前加h3c前缀，如h3c workspace slot cache show。

3. 其他辅助排查命令

• Onestor存储：执行 onestor-tool cache status，查看具体哪个slot状态为error或fault。

• 超融合平台：执行 ssmcli show disk 查看磁盘状态，或 ssmcli show cache 查看缓存池状态。

• 检查OSD：执行 ceph osd tree，查看是否有OSD状态为down或异常。

 方案三：查看系统日志

若命令无法定位，需查看后台日志寻找错误线索。

cache.log日志可帮助判断是元数据损坏还是分区残留。

 后续处理建议

确认异常后，可根据情况处理：

• 软清理：workspace slot cache reset --node <节点ID> --slot <槽位号>。

• 严重异常：考虑解绑异常slot的缓存，再重新绑定

您好，参考

排查操作顺序

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 缓存异常现象。