错误的字节有时会写入磁盘。硬件问题？
Wrong bytes are sometimes written to disk. Hardware problems?
我已经使用 C++ 11 (VS2013) 编写了基于 UDP 的传输协议。它运行速度极快 - 并且在 99.9% 的时间里运行良好。
但我几次观察到错误的字节被写入磁盘（三星 250 GB SSD 850 EVO）——或者至少看起来是这样。
这基本上是我传输 6GB 测试文件时有时会发生的情况：
- 文件被分割成更小的 UDP 数据包 - 大小为 64K。 （网络层将 UDP 数据报分解并重组为更大的包）。
- 客户端将数据包 (udp) 发送到服务器 - 负载使用 AES256 (OpenSSL) 加密并包含数据 + 元数据。有效负载还包含整个有效负载的 SHA256 哈希值——作为对 UDP 校验和进行补充的额外完整性检查。
- Server收到数据包，返回一个"ACK"包给Client，然后计算SHA256 Hash。哈希与客户端哈希相同 - 一切都很好
- Server然后将package的数据写入磁盘（由于性能差异巨大，使用fwrite而不是streams）。服务器一次只处理一个包 - 每个文件指针都有一个互斥锁保护器，可以保护它不被另一个工作线程关闭，该工作线程关闭了 10 秒不活动的文件指针。
- 客户端收到 UDP "ACK" 包并重新发送尚未确认的包（意味着他们没有成功）。传入 ACK 包的速率控制客户端的发送速度（又名拥塞 control/throtteling）。服务器上收到的包的顺序无关紧要，因为每个包都包含一个位置值（数据应写入文件中的位置）。
传输整个文件后，我在服务器和客户端上对 6GB 文件进行了完整的 SHA256 哈希处理，但令我恐惧的是，最近几天我两次观察到该哈希值是 不相同（进行大约 20 次测试传输时）。
在Beyond Compare中比较文件后，我通常会发现服务器端有一两个位[=54=]（在一个6GB的文件中）是错误的。
见下图：
服务器代码 - 在验证数据包哈希后调用
void WriteToFile(long long position, unsigned char * data, int lengthOfData){
boost::lock_guard<std::mutex> guard(filePointerMutex);
//Open if required
if (filePointer == nullptr){
_wfopen_s(&filePointer, (U("\\?\") + AbsoluteFilePathAndName).c_str(), L"wb");
}
//Seek
fsetpos(filePointer, &position);
//Write - not checking the result of the fwrite operation - should I?
fwrite(data, sizeof(unsigned char), lengthOfData, filePointer);
//Flush
fflush(filePointer);
//A separate worker thread is closing all stale filehandles
//(and setting filePointer to NULLPTR). This isn't invoked until 10 secs
//after the file has been transferred anyways - so shouldn't matter
}
所以总结一下：
- 服务器内存中的 char * 是正确的 - 否则服务器 SHA256 哈希会失败 - 对吗？ （与 sha256 的哈希冲突极不可能）。
- 写入磁盘时似乎发生损坏。由于在发送 6GB 文件时大约有 95.000 个 64k 包写入磁盘 - 而且它只发生一次或两次（当它发生时） - 意味着这是一种罕见的现象
怎么会这样？这是我的硬件（坏 ram/disk）造成的吗？
我真的需要在写入后从磁盘读取数据吗？ memcmp 以便 100% 确定将正确的字节写入磁盘？
（哦，天哪 - 这将是多么出色的表现......）
在我的本地电脑上 - 结果是内存问题。 运行ning memtest86 发现。
尽管如此 - 我修改了生产服务器上 运行 的软件代码 - 使其从磁盘读取以验证实际上写入了正确的字节。这些服务器每天将大约 10TB 的数据写入磁盘 - 在使用新代码 运行 一周后 - 错误发生了一次。该软件通过再次写入和验证来纠正这个问题——但看到它确实发生了仍然很有趣。
560000000000000 位中有 1 位被错误写入磁盘。厉害了。
稍后我可能会 运行 此服务器上的 memtest86 以查看这是否也是 RAM 问题 - 但我不再真正担心这个问题，因为文件完整性或多或少得到了保证，并且否则服务器没有显示硬件问题的迹象。
所以 - 如果文件完整性对您来说非常重要（就像对我们一样）- 那么请不要 100% 信任您的硬件并验证 reading/writing 操作。异常可能是硬件问题的早期迹象。
我已经使用 C++ 11 (VS2013) 编写了基于 UDP 的传输协议。它运行速度极快 - 并且在 99.9% 的时间里运行良好。
但我几次观察到错误的字节被写入磁盘（三星 250 GB SSD 850 EVO）——或者至少看起来是这样。
这基本上是我传输 6GB 测试文件时有时会发生的情况：
- 文件被分割成更小的 UDP 数据包 - 大小为 64K。 （网络层将 UDP 数据报分解并重组为更大的包）。
- 客户端将数据包 (udp) 发送到服务器 - 负载使用 AES256 (OpenSSL) 加密并包含数据 + 元数据。有效负载还包含整个有效负载的 SHA256 哈希值——作为对 UDP 校验和进行补充的额外完整性检查。
- Server收到数据包，返回一个"ACK"包给Client，然后计算SHA256 Hash。哈希与客户端哈希相同 - 一切都很好
- Server然后将package的数据写入磁盘（由于性能差异巨大，使用fwrite而不是streams）。服务器一次只处理一个包 - 每个文件指针都有一个互斥锁保护器，可以保护它不被另一个工作线程关闭，该工作线程关闭了 10 秒不活动的文件指针。
- 客户端收到 UDP "ACK" 包并重新发送尚未确认的包（意味着他们没有成功）。传入 ACK 包的速率控制客户端的发送速度（又名拥塞 control/throtteling）。服务器上收到的包的顺序无关紧要，因为每个包都包含一个位置值（数据应写入文件中的位置）。
传输整个文件后，我在服务器和客户端上对 6GB 文件进行了完整的 SHA256 哈希处理，但令我恐惧的是，最近几天我两次观察到该哈希值是 不相同（进行大约 20 次测试传输时）。
在Beyond Compare中比较文件后，我通常会发现服务器端有一两个位[=54=]（在一个6GB的文件中）是错误的。
见下图：
服务器代码 - 在验证数据包哈希后调用
void WriteToFile(long long position, unsigned char * data, int lengthOfData){
boost::lock_guard<std::mutex> guard(filePointerMutex);
//Open if required
if (filePointer == nullptr){
_wfopen_s(&filePointer, (U("\\?\") + AbsoluteFilePathAndName).c_str(), L"wb");
}
//Seek
fsetpos(filePointer, &position);
//Write - not checking the result of the fwrite operation - should I?
fwrite(data, sizeof(unsigned char), lengthOfData, filePointer);
//Flush
fflush(filePointer);
//A separate worker thread is closing all stale filehandles
//(and setting filePointer to NULLPTR). This isn't invoked until 10 secs
//after the file has been transferred anyways - so shouldn't matter
}
所以总结一下：
- 服务器内存中的 char * 是正确的 - 否则服务器 SHA256 哈希会失败 - 对吗？ （与 sha256 的哈希冲突极不可能）。
- 写入磁盘时似乎发生损坏。由于在发送 6GB 文件时大约有 95.000 个 64k 包写入磁盘 - 而且它只发生一次或两次（当它发生时） - 意味着这是一种罕见的现象
怎么会这样？这是我的硬件（坏 ram/disk）造成的吗？
我真的需要在写入后从磁盘读取数据吗？ memcmp 以便 100% 确定将正确的字节写入磁盘？ （哦，天哪 - 这将是多么出色的表现......）
在我的本地电脑上 - 结果是内存问题。 运行ning memtest86 发现。
尽管如此 - 我修改了生产服务器上 运行 的软件代码 - 使其从磁盘读取以验证实际上写入了正确的字节。这些服务器每天将大约 10TB 的数据写入磁盘 - 在使用新代码 运行 一周后 - 错误发生了一次。该软件通过再次写入和验证来纠正这个问题——但看到它确实发生了仍然很有趣。
560000000000000 位中有 1 位被错误写入磁盘。厉害了。
稍后我可能会 运行 此服务器上的 memtest86 以查看这是否也是 RAM 问题 - 但我不再真正担心这个问题，因为文件完整性或多或少得到了保证，并且否则服务器没有显示硬件问题的迹象。
所以 - 如果文件完整性对您来说非常重要（就像对我们一样）- 那么请不要 100% 信任您的硬件并验证 reading/writing 操作。异常可能是硬件问题的早期迹象。