有什么办法可以加快频繁的文件写入操作吗？ C文件
我的任务是频繁且有保证地将小部分数据写入文件。它是某种类型的日志系统，必须提供有保证的安全性和将数据保存到磁盘的速度。我发现刹车出现在调用过于频繁的 Flush() 函数中。所以，我决定摆脱它。
我使用了禁止缓冲和缓存数据的标志（osNoBuffer 和 writeThrough）。之后，据我了解，我可以在不使用flush()的情况下执行文件I/O操作（将数据写入文件）？ 还有一个问题。我怎么能理解数据肯定是写入磁盘而没有缓存和缓冲呢？ 这是做我想做的事情的正确方法还是可能是加速频繁文件写入操作的其他方法？
My task is to write small parts of data to file frequently and guaranteed. It's a some type of logging system, that must provide a guaranteed safety and speed of saving data to disk. I found that brakes appear in the Flush() function that is called too often. So, I decided to get rid of it.
I used flags, that prohibit buffering and caching data (osNoBuffer and writeThrough). After this, as I understand, I could perform file I/O operations (write data to file) without use of flush()?
Another one question. How can I understand that data is definitely written to disk without caching and buffering?
Is it The wright way to do what I want or may be the other way to speed up frequent file write operations??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
flush()花费这么长时间，正是因为它建立了您正在寻找的保证。文件通常写入磁盘，磁盘（可能）正在旋转生锈的磁盘。文件物理上分散在这些磁盘的表面上，将读/写头移动到正确的位置需要几毫秒的时间。每秒 50 次刷新意味着每次刷新平均需要 20 毫秒，这接近磁盘的机械性能。如果没有刷新，您的写入将被合并，因此多个写入只需要读/写头的一次移动。即使不检查特定标志，这也必然意味着数据暂时面临风险。
仅在软件中，您永远无法知道数据是否真正写入磁盘。我们知道这一点是因为 Sun 在开发 ZFS 文件系统时进行的研究。事实证明，更便宜、更慢的磁盘在刷新方面存在缺陷，并在数据实际刷新之前返回。您将需要服务器级磁盘来保证这一点。
SSD在这方面表现相当出色。他们不需要物理移动写入头。因此，他们在同花问题上撒谎的动机较小。
flush()takes so long, precisely because it establishes the guarantee you're looking for. Files are usually written to disk, which (probably) are spinning rusty disks. Files are physically scattered over the surface of these disks, and it takes milliseconds to move the read/write head to the right place. 50 flushes per second means an average of 20 milliseconds per flush, which is close to what your disk mechanically can do.Without flush, your writes are combined so multiple writes will require only one movement of the read/write head. Without even examining the specific flags, that must necessarily mean that data is temporarily at risk.
In software alone, you can never know whether data is truly written to disk. We know this because of research performed by Sun, when developing the ZFS file system. It turns out that cheaper, slower disks lie about flushing, and return before data is actually flushed. You will need server-grade disks to guarantee this.
SSDs perform quite well in this area. They have no need to physically move write heads. Therefore, there's less incentive for them to lie about flushes.