6.8. 文件系统和存储
multipathd 现在成功删除带有未排队的 I/O 的设备
					在以前的版本中,multipathd 命令在删除设备前不会禁用 queue_if_no_path 参数。这只有在多路径设备本身有未完成的 I/O 且不是分区设备时,才能实现。因此,multipathd 会挂起,且无法维护多路径设备。在这个版本中,multipathd 在执行 remove 命令前禁用排队,如 multipath -F,multipath -f <device> , multipathd remove map , 或  。现在,multipathd remove map <device>multipathd 可以成功删除带有未排队的 I/O 的设备。
				
Jira:RHEL-4998[1]
dm-crypt 和 dm-verity 设备的 no_read_workqueue、no_write_workqueue 和 try_verify_in_taskle 选项会被临时禁用
					在以前的版本中,使用 no_read_workqueue 或 no_write_workqueue 选项和 dm-verity 设备创建的 dm-crypt 设备以及使用 try_verify_in_tasklet 选项创建的 dm-verity 设备会导致内存崩溃。因此,随机内核内存被破坏,这会导致各种系统问题。在这个版本中,这些选项会被临时禁用。请注意,这个修复可能会导致 dm-verity 和 dm-crypt 在某些工作负载中执行较慢。
				
Jira:RHEL-23572[1]
multipathd 现在检查设备是否错误地排队 I/O
在以前的版本中,多路径设备会在以下条件下重启排队 I/O,即使它被配置为失败:
- 
						多路径设备配置了 queue_if_no_paths参数,设置为重试次数。
- 路径设备已从没有工作路径的多路径设备中删除,不再排队 I/O。
在这个版本中,这个问题已被解决。因此,如果禁用了排队,且在没有可用路径时删除路径,则多路径设备不再重启排队 I/O。
Jira:RHEL-17234[1]
从 nvmf_log_connect_error中删除重复条目
					在以前的版本中,由于重复的提交合并错误,在 nvmf_log_connect_error 内核功能中重复日志消息。因此,当内核无法连接到光纤附加的 Non-volatile Memory Express (NVMe)设备时,Connect 命令会失败 消息两次。在这个版本中,重复日志消息已从内核中删除,从而导致每个错误都只有一个日志消息可用。
				
Jira:RHEL-21545[1]
在添加和删除命名空间时,内核不再崩溃
					在以前的版本中,当快速添加和删除 NVMe 命名空间时,命名空间会在用于探测命名空间的连续命令间消失。在特定情况下,存储阵列不会返回 无效的命名空间 错误,而是返回一个带有零的缓冲区。因此,内核会因为 divide-by-zero 错误而崩溃。在这个版本中,内核会从向存储发布的 Identify 命名空间数据结构的响应验证数据。因此,内核不再崩溃。
				
Jira:RHEL-14751[1]
现在,数据设备的新分配的部分已被正确对齐
					在以前的版本中,当扩展 Stratis 池时,可以分配池的新区域。但是新分配的区域没有与之前分配的区域正确一致。因此,可能会导致性能下降,以及 sysfs 中 Stratis 精简池的 alignment_offset 文件中的非零条目。在这个版本中,当池扩展时,数据设备的新分配的区域与之前分配的区域正确一致。因此,在 sysfs 中,性能没有降级,在 Stratis 精简池的 alignment_offset 文件中没有非零条目。
				
当在 /etc/fstab中将 NVMe-FC 设备添加为挂载点时,系统可以正确启动
					在以前的版本中,由于 nvme-cli nvmf-autoconnect systemd 服务中的一个已知问题,在将光纤通道上的 Non-volatile Memory Express (NVMe-FC)设备添加为 /etc/fstab 文件中的挂载点时,系统无法引导。因此,系统进入紧急模式。有了此更新,当挂载 NVMe-FC 设备时,系统可以引导,而没有任何问题。
				
Jira:RHEL-8171[1]
LUN 现在在操作系统安装过程中可见
在以前的版本中,系统没有使用固件源的身份验证信息,特别是在涉及带有存储在 iSCSI iBFT (Boot Firmware Table)中 CHAP (Challenge-Handshake Authentication Protocol) 的 iSCSI 硬件卸载的情况。因此,在安装过程中 iSCSI 登录失败。
				有了udisks2-2.9.4-9.el9 固件身份验证中的修复,这个问题已被解决,LUN 在安装和初始引导过程中可见。
			
Bugzilla:2213769[1]