阵列初始化是什么
新建或重建逻辑盘后，控制器需要做初始化。Fast Init 只写必要元数据并把逻辑盘标记为可初始化状态，几秒到几分钟完成；Full Init 会把成员盘整盘写零并建立初始校验，耗时与容量成正比，好处是能把历史遗留的坏块提前暴露出来。对复用过的旧盘，做一次完整初始化比直接上线更稳妥。
两种初始化
| 类型 | 动作 | 耗时 | 适用 |
|---|---|---|---|
| Fast Init | 写元数据、置位初始化标志 | 秒级到分钟级 | 新盘或可信盘 |
| Full Init | 全盘写零，校验位一并建立 | 小时级（随容量） | 复用旧盘、交付前 |
基本信息
| 执行入口 | storcli /c0/v0 start init full，进度用 show init 查看 |
|---|---|
| 后台初始化 | 部分卡支持后台初始化（BGI），可先上线数据再逐步完成 |
| 性能影响 | 完整初始化期间阵列 IO 能力下降，不宜作为性能测试环境 |
| 与重建的区别 | 初始化是建立初始数据与校验，重建是用冗余恢复数据 |
查看与启动初始化
查看与启动初始化
storcli /c0/v0 show all | grep -i "init" # 查看初始化状态
storcli /c0/v0 start init full # 启动完整初始化
storcli /c0/v0 start init fast # 启动快速初始化
storcli /c0/v0 show init # 查看进度
storcli /c0/show events | tail -20 # 初始化相关事件留档典型使用场景
- 新盘建阵列：盘体可信时用快速初始化，缩短交付时间
- 旧盘复用：先做完整初始化，把历史坏块提前暴露在交付阶段
- 交付前验收：完整初始化后跑一轮读写校验，作为交付证据
- 业务窗口紧张：使用后台初始化，先上线再让初始化在后台完成
- 故障后重建到新盘：确认新盘状态后再决定初始化方式
怎么选
| 场景 | 建议 | 原因 |
|---|---|---|
| 全新企业盘 | 快速初始化 | 盘体可信，节省交付时间 |
| 来源不明或复用盘 | 完整初始化 | 提前暴露坏块，避免运行期踩坑 |
| 上线时间敏感 | 后台初始化 | 兼顾交付速度与初始化完整性 |
| 交付验收场景 | 完整初始化加读写校验 | 把隐患留在交付阶段而不是运行期 |
完整初始化期间不要作为存储性能测试环境；部分卡允许后台初始化（BGI），可先上线数据。
初始化与重建在工具里都会显示百分比进度，含义完全不同：看进度前先确认任务类型，别把初始化进度误读为数据恢复。
常见疑问
- 快速初始化后盘上还有旧数据吗：元数据被重建，旧数据不可通过正常途径访问，但物理上可能残留
- 完整初始化能否中断：中断会留下未完成状态，后续通常需要重新执行
- 后台初始化期间能否做一致性检查：不建议同时运行多个后台任务，IO 会互相争抢