早上好,
我有这样的配置:
发布于 2020-03-01 15:06:10
在深入研究这个问题之后,我想我本可以找到解决办法的。
我没有使用/dev/sd*设备文件作为iscsi目标的备份存储,而是使用/dev/sg*
与此配置对应的:
<target iqn.2018-02.test.it:lun1>
<backing-store /dev/sg0>
bs-type sg
device-type pt
</direct-store>
</target>正如我想的那样,也许解决方案可能与块设备上的页面缓存有关,也许使用直接命令的sg绕过了这个.我不知道。
更改配置后,我成功地尝试在主机A、D和E上挂载。
在/var/ log /messages上,我发现了ocfs2正常工作时A、D和E连接的日志。
我还创建了一个测试文件,并在每个主机上更新。
我将在本周进行更多的测试,看看是否会有数据损坏,并相应地更新帖子。
马泰奥
更新
它似乎工作正常,但当从iscsi (启动器)上的主机在共享磁盘上执行一个大副本(超过1Gb的文件)时,主机崩溃并在目标tgt上显示此错误:
mar 04 17:09:29 debian-shdisk-iscsi tgtd[1515]: tgtd: bs_sg_cmd_submit(228) failed to start cmd 0x0x559a50768510
mar 04 17:09:29 debian-shdisk-iscsi tgtd[1515]: tgtd: graceful_write(87) sg device 11 write failed, errno: 33scsi通用linux内核4.19驱动程序中的errno 33 (EDOM)似乎是在cmd队列满时在写入过程中触发的。在tgtd端,这似乎不被处理,它会触发在启动器端生成块错误的错误。有什么建议吗?
https://serverfault.com/questions/1005031
复制相似问题