c++ - 错误的字节有时会写入磁盘。硬件问题？

Question

我使用 C++ 11 (VS2013) 编写了一个基于 UDP 的传输协议(protocol)。它运行速度极快 - 并且在 99.9% 的时间内运行良好。

但我几次观察到错误的字节被写入磁盘(三星 250 GB SSD 850 EVO)——或者至少看起来是这样。

这基本上是我传输 6GB 测试文件时有时会发生的情况:

1. 文件被分割成更小的 UDP 数据包——大小为 64K。 (网络层将 UDP 数据报分解并重新组装成更大的包)。
2. 客户端将数据包 (udp) 发送到服务器 - 负载使用 AES256 (OpenSSL) 加密并包含数据 + 元数据。有效负载还包含整个有效负载的 SHA256 哈希值——作为对 UDP 校验和进行补充的额外完整性检查。
3. 服务器收到数据包，将“ACK”包发回给客户端，然后计算SHA256哈希值。散列与客户端散列相同 - 一切都很好
4. 服务器然后将包的数据写入磁盘(由于巨大的性能差异，使用 fwrite 而不是流)。服务器一次只处理一个包 - 每个文件指针都有一个互斥锁保护器，可以保护它不被另一个工作线程关闭，该工作线程关闭了 10 秒不活动的文件指针。
5. 客户端收到 UDP“ACK”包并重新发送尚未确认的包(意味着它们没有成功)。传入 ACK 包的速率控制客户端的发送速度(也称为拥塞控制/节流)。服务器上收到的包的顺序无关紧要，因为每个包都包含一个位置值(数据应写入文件中的位置)。

在传输整个文件后，我在服务器和客户端上对 6GB 文件进行了完整的 SHA256 哈希处理，但令我恐惧的是，最近几天我两次观察到该哈希值不是 相同(进行大约 20 次测试传输时)。

在 Beyond Compare 中比较文件后，我通常会发现服务器端有一两个位(在一个 6 GB 的文件中)错误。

请参见下面的屏幕截图:

服务器代码 - 在验证 DataPackage 哈希后调用

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 包写入磁盘 - 而且它只发生一次或两次(当它发生时) - 意味着这是一种罕见的现象

这怎么会发生？这是我的硬件(坏内存/磁盘)造成的吗？

我真的需要在写入后从磁盘读取数据吗？ memcmp 以便 100% 确定将正确的字节写入磁盘？(哦，天哪——这将是多么出色的表现……)

Answer 1

在我的本地电脑上 - 结果是内存问题。通过运行 memtest86 发现。

尽管如此 - 我修改了在我们的生产服务器上运行的软件代码 - 使其从磁盘读取以验证是否确实写入了正确的字节。这些服务器每天将大约 10TB 的数据写入磁盘——在运行新代码一周后——错误发生了一次。该软件通过再次写入和验证来纠正这个问题——但看到它确实发生了仍然很有趣。

560000000000000 位中的 1 位被错误写入磁盘。太棒了。

稍后我可能会在此服务器上运行 memtest86 以查看这是否也是 RAM 问题 - 但我不再真的非常担心这个问题，因为文件完整性或多或少得到了保证，并且服务器没有显示任何迹象否则硬件问题。

因此 - 如果文件完整性对您来说极其重要(就像对我们一样)- 那么请不要 100% 信任您的硬件并验证读/写操作。异常可能是硬件问题的早期迹象。