我已经研究过这个错误，但似乎还没有讨论过——或者至少我找不到任何相关信息。
我在传输文件时遇到问题，通常是传输几百 MB 以上的大文件。
设置如下：
- QNAP 410 作为具有多个 LUN 的 iSCSI 目标。（CRC 已打开（数据摘要和标头摘要）
- 带有 iSCSI Initiator 版本 2.08 - 内部版本 3825 的 Server 2003
（我正在将文件从另一台机器复制到 Server 2003 上的共享 => 复制到 TrueCrypt 卷，然后复制到 NAS 上）
我已经安装了 LUN 并使用 TrueCrypt 使用 NTFS 对其进行了格式化（完整格式化，而不是快速格式化）。
某些文件（主要是 RAR/压缩文件）似乎已复制但失败了。我已通过多种方式测试过此问题，每次都可以重复该过程。
因此我想检查一下不带 TrueCrypt 的 iSCSI 传输，采用普通的 NTFS 格式 - 完全没有问题。
因此看起来 TrueCrypt 至少是这里问题的一部分。
我还没有尝试过直接从服务器复制，我会尝试的。我也没有尝试过不使用 CRC，但不知道这会有什么影响。我稍后会更新我的发现。
与此同时，有人知道可能出了什么问题吗？
谢谢你的时间。
更新：
我将一组文件（我遇到问题的文件）复制到服务器，然后从那里将它们复制到 TrueCrypt 卷内的两个位置（安装在 NAS 上）。
- 在卷的根目录中创建一个单独的目录
- 我最初使用的初始目录相同
两者都运行良好。所以现在看来，这是 TrueCrypt、iSCSI 和 Windows Shares 之间的联系。
我之所以这么说，是因为我最初使用 TrueCrypt 卷文件而不是 iSCSI 设置了整个系统。我更改了它，因为它不符合我的要求 - 也浪费了一天时间。虽然我有这个设置，但我将整个文件集复制到卷文件中，并且所有文件都无误地复制了 - 通过网络，从 PC 复制到 TrueCrypt 从 NAS 安装卷文件的服务器。
我没有关闭 iSCSI 系统上的 CRC，因为根据这一发现，我非常怀疑这是原因。
那么有什么想法吗？
答案1
因此经过大量测试后我决定回答我自己的问题。
根据 Truecrypt 文档，他们不支持使用 iSCSI 的这种设置。我明白了 - 很多事情都可能出错，但这难道不应该是经过测试和支持的东西吗？
长话短说，我预期的设置在 Server 2008 (RC2) 上完美运行，因此看起来它已本地化到 Server 2003（或者更具体地说，它可能是一个运行 Server 2003 的 VM）。通过 iSCSI 的传输速度也快得多，不确定这是否直接相关，但我认为我会把它放在那里。