什么是无法读取的扇区管理?
适用场景
NetApp E 系列产品
问题解答
- 不可读扇区管理(Unm读取 扇区管理、USM)功能提供了一种基于控制器的方法、用于处理在正常I/O处理和重建等长时间运行操作期间检测到的不可读扇区。
- 此功能主要对最终用户透明、因此没有可用的可配置选项、并且无法禁用此功能。
- USM提供的五个主要功能改进包括:
- 在主要事件日志(MEL)中更好地报告无法读取的扇区(以及与USM相关的情况)。
- 持续报告无法读取的扇区。
- 尽管存在介质错误,但所有重建和其它长期运行操作都将继续进行。
- 即使无法生成奇偶校验,也能成功完成对最佳 RAID 5 卷的写入。
- 通过RAID重新配置操作(动态容量扩展(DCE)动态卷扩展(DVE)动态)持久保留介质错误情况。
- 由于NetApp在一个子系统中同时支持FC-SCSI和SATA磁盘、因此该功能的设计不依赖于物理磁盘功能、并且可在控制器固件中完全处理。
- 但是、控制器固件不会尝试模拟本机不支持这些功能的磁盘的功能。
- 在本文中、"不可读扇区"是指由于非冗余卷(RAID 0)上存在物理磁盘介质相关的双重故障或与物理磁盘介质相关的单个故障情况而被视为完全不可读的卷逻辑块地址(LBA)。
- 无法读取的扇区是不可恢复的、该位置包含的数据应视为丢失、必须通过其他方式进行恢复。
无法读取的扇区数据库如何工作以及它记录了哪些内容?
- 无法读取的扇区数据库会保留在稳定的存储中、并为检测到的每个不可读取扇区提供一个条目。
- 它使用以卷为中心的信息进行记录、其中包括:
- 唯一卷标识符(非SSID)
- 卷LBA
- 块计数
- 将数据库保持在稳定存储中的优势在于、它可以持久报告无法读取的扇区、因为它可以在重新启动、卷重新配置和固件升级(前提是升级到支持USM的代码)、卷状态更改和卷传输之后继续运行。
要查看 USM 数据库:
- 在 SANtricity (阵列管理窗口)中,转到 监控 >> 报告 >> "不可读扇区日志"
- SANtricity CLI 命令:
show storageArray unreadableSectors
- 在 SANtricity Array Manager ( SAM )中,转至 Support (支持) >> Support Center (支持中心) >> Diagnostics (诊断)选项卡 >> Selecting "View/Clear Unreadable Sects" (查看 / 清除无法读取的扇区)
如何以及为什么在数据库中输入不可读的扇区?
- 在执行任何读取操作时、都可以向无法读取的扇区数据库输入条目、无论是主机I/O还是需要从物理介质读取的内部操作。
- 对于冗余配置、这意味着数据和奇偶校验(或镜像)位置都可以为无法读取的扇区数据库生成条目。
- 在主机读取I/O期间、如果物理磁盘返回介质错误、则控制器将首先尝试重建数据(采用最佳冗余配置)。
- 如果重建该数据失败、则会进入无法读取的扇区数据库、并且主机I/O将失败、并显示检测关键字Hardware Error (0x04)。
带冗余的介质扫描检查:
- 在扫描期间、将读取和比较所有数据和奇偶校验信息。
- 遇到介质错误时、无论是新介质错误还是已记录在数据库中的介质错误、都会执行以下操作。
- 系统将尝试在该位置重建数据、如果成功、将对磁盘执行回写操作。
- 如果无法读取的扇区数据库中存在写入位置条目、则该条目将被删除。
- 如果无法重建数据、则会在数据库中为涉及的所有无法读取的扇区输入条目。
重建:
- 读取将在RAID5重建期间进行处理。
- 如果在无法读取的扇区数据库中找到现有条目、则重建驱动器上的相应扇区将添加到无法读取的扇区数据库中、并为重建驱动器上丢失的数据生成严重的MEL事件。
- 重建驱动器上的扇区将使用已知数据模式写入。
- 如果在执行RAID 5重建期间从磁盘返回新介质错误、则会出现两种情况:
数据段上发生读取错误
- 已执行此操作:
- 无法读取的扇区数据库将添加两个无法读取的扇区、一个用于数据驱动器上的故障扇区、另一个用于无法在重建驱动器上重新生成的数据。
- 由于这两个扇区的用户数据都丢失、因此会为这两个扇区生成严重的MEL事件。
- 由于执行此操作、奇偶校验驱动器的内存表中将添加一个无法读取的扇区条目。
奇偶校验段上发生读取错误
- 已执行此操作:
- 将在无法读取的扇区数据库中输入无法在重建驱动器上重新生成的位置。
- 系统将为丢失的用户数据记录一个MEL事件。
- 内存表中还会添加一个条目、用于说明奇偶校验驱动器上的位置。
- 读取将在RAID 1重建期间进行处理。
- 如果在无法读取的扇区数据库中找到现有条目、则重建驱动器上的相应扇区将使用已知数据模式写入、并且不会生成任何MEL事件。
- 如果在重建过程中从源磁盘遇到新介质错误、则故障扇区将添加到数据库中、并生成严重的MEL事件。
- 重建驱动器将使用默认模式写入。
复制回操作:
- 在复制回操作期间、系统将读取热备用驱动器并将其复制到替代驱动器。
- 如果在数据库中发现现有的不可读扇区、则不会创建新条目、并且会更新逻辑到物理的映射。如果检测到新的不可读扇区、则会尝试重建数据。
- 如果无法恢复数据、则会为目标扇区添加一个新的不可读取扇区条目、并生成一个严重的MEL事件。
- 目标扇区将使用已知数据模式写入、并且复制回操作将继续完成。
即时可用性格式(Immediate Availability Format、IA
- 当IAF检测到介质错误时、它会在不可读扇区数据库中为不可读扇区和相应的奇偶校验块放置一个条目。
- 为介质错误站点生成严重的MEL事件。
动态重新配置
- 执行卷重新配置时、卷组中的驱动器数量、RAID级别或条带大小可能会发生变化。
- 只有在数据库中尚未存在现有条目时、才会记录在此操作期间在源上检测到的不可读扇区。
- 这些不可读块将迁移到目标配置中的新位置、更新逻辑块不可读扇区数据库中的物理位置、并生成MEL事件。
- 实施USM并不能保证物理介质错误不会影响用户对其数据的访问。
- 无法读取的扇区管理旨在通过向最终用户提供存在这些错误的通知来减少这种可能性。
- 如果将USM与介质扫描等功能结合使用、则系统管理员可以有机会主动采取措施、防止硬件问题影响数据访问。
- 与已记录在不可读扇区数据库中的扇区交叉的主机读取将返回一个检测密钥0x03 (中等错误)和一个ASC/SCQ 0x11/0x00 (不可恢复的读取错误)。
- 有一个限制因素、即不可读扇区数据库最多只允许1000个条目。
- 此1000条目限制适用于所有卷组、卷和磁盘。
- 数据库已满后、控制器的行为如下所示:
- 对于重建期间遇到的新的不可读扇区、重建驱动器失败、但不会对不可读扇区数据库输入任何条目。
- 对于在主机I/O期间遇到的新的不可读取扇区、主机I/O将失败、并且不会输入任何条目。
- 对于在数据库已满后检测到的所有新的不可读扇区、将生成严重的MEL事件。
- 此后每次尝试访问此位置都会生成严重事件、因为无法在数据库中为其创建条目。
清除不可读扇区数据库:可以通过以下方法之一从不可读扇区数据库中删除条目
- 用户请求:
- 用户可以通过SANtricity 图形用户界面或SANtricity 命令行界面脚本请求清除指定卷、卷组或整个子系统的数据库条目。
- 此类型的请求会清除指定级别的所有不可读扇区、并导致发生以下情况:
- 要写入相应扇区的已知数据模式。
- 要为包含不可读扇区的条带生成正确的奇偶校验。
- 要从数据库中删除的条目。
- 在SANtricity 中、可以查看不可读扇区条目、并转到"监控">"报告">>"不可读扇区日志"来选择清除选项。
- 或者使用以下SANtricity 命令行界面脚本清除条目:
clear allVolumes unreadableSectors;
- 或者使用以下SANtricity 命令行界面脚本清除条目:
- 在控制器SAM中、转至支持>>支持中心>>诊断选项卡>>选择"查看/清除不可读扇区">>选择一个条目>>清除。
- 成功写入:
- 成功写入USM数据库中输入的扇区也会删除该条目。
- 如果发生与已知不可读扇区交叉的写入、则该写入将转换为写入并进行验证、以确保该扇区已修复并可读。
- 如果WRITE AND VERIFY返回的状态良好、则会从数据库中删除该扇区。
USM 施加的限制:如果某个卷组或卷的数据库中存在无法读取的扇区、则某些功能将被禁用。
- 远程卷镜像(RVM)
- 如果主卷存在不可读的扇区条目、则控制器固件将拒绝创建镜像关系。
- 如果在同步期间遇到无法读取的扇区、则同步和镜像关系都将失败。
- 快照:
- 只要卷的USM数据库中存在条目、控制器固件就会拒绝创建快照。
- 此适用场景 同时对源卷和关联的存储库卷执行。
- 卷副本:
- 如果源卷在USM数据库中包含不可读的扇区条目、则控制器固件将拒绝卷复制请求。
- 重新配置操作:
- 控制器固件将拒绝对USM数据库中的扇区条目不可读的卷发出的卷重新配置请求。
- 卷导入:
- 如果导入的卷组发生原因 会导致无法读取的扇区数据库溢出、则导入将失败、新卷将保持脱机状态。
- 此时将生成MEL事件并记录恢复guru操作、并说明必须减少无法读取的扇区数据库中的条目数、然后才能执行导入。
追加信息
注意:如果您无法查看本文的全部内容、请登录 到NetApp知识库