现象
9560 -16i Raid 正常加载数据刷新后，OS 重启；Raid 卡信息长时间无法更新出数据
初步分析
调用接口超时
诉求
1、请问这种情况，应该通过何种手段继续分析？
2、这种情况可能原因？
初步分析
调用接口超时
诉求
1、请问这种情况，应该通过何种手段继续分析？
2、这种情况可能原因？
可以把对应的版本给一下吗？
这个问题后续版本已经有进行优化了
组件版本就是标题的 1.70.35
优化的pr 叫啥 我去 参考一下
这个是只改了 storage 组件吗？
还有涉及一些闭源的修改，单独改storage仓的可能还不行，马上应该会发布，能否等发布完了之后看一下。目前看到硬盘日志收集（function c_drive:dump_drive_log()）是比较耗时的，你这个环境硬盘又比较多，大概率是这一部分阻塞住了。
建议：后面提问可以把：storage, libprotocol仓的版本号都提供一下
1 个赞
这版本是基于社区330版本开发
storage 1.70.35
libprotocol 1.70.27
那我们下面这样是否可行
因为项目节点紧急，我们打算先基于330版本，同步 630 版本 storage 修改点
其中 storage 630 conan 依赖点 只有 lib protocol 组件
lib protocol 依赖 我们就不清楚了
你好，这里描述的修改点是 storage 哪个修改点，PR已经合入了吗？我们准备同步一下
你们是有自己的分支吗，storage合入了这个PR lib protocol的修改 6.30开出去的应该带上了
修改双Raid卡升级riser时间超出基线问题-storage-GitCode
确定是这个方法解决的 debus 超时吗？
我们同步这个修改点后 仍有很多超时日志
动作如下
我们基于330版本 专门同步了 [修改双Raid卡升级riser时间超出基线问题] 这个问题 的
storage、lib_protocol （PAE 处理）、storelib（PAE 处理） 三个组件
目前的解决办法有
1.storage使用使用带优先级的接口
2.storelib库 sleep时间错误整改，重试次数调整
3.丢弃已经超时的读请求
4.os下电时，停止注册RAID卡
如果这些修改都带上了修改，需要打开storelib的日志继续定位了