我的要求是将传入的可变大小的二进制消息的永不结束的流写入文件系统。平均大小为2KB的消息达到1000条消息/秒。因此，在一小时内，消息总数将为3600 * 1000 * 2 = 6.8 GB。 消息的主要目的如下 1.将它们存档以用于审计目的 2.提供搜索界面
我的问题是
答案 0 :(得分：2)
一旦write或writev返回（即操作系统已接受它），操作系统负责将数据写入磁盘。这不再是你的问题了，而且无论你的进程崩溃了，都会发生这种情况。请注意，您对一次接受或实际写入的数据的确切数量无控制，也不管文件系统块的倍数是否发生，或者它是否具有任何特定大小。您向<{1}}发送请求，它会告诉您实际接受了多少，并且会根据自己的判断将其写入磁盘。
可能这会以块大小的倍数发生，因为它对操作系统来说是有意义的，但这无法以任何方式保证（在许多系统上，包括Linux，读取和写入是通过或与文件映射紧密结合）。
同样的“不必关心”保证文件映射（理论上除了崩溃的应用程序原则上仍可写入静态映射区域，但一旦取消映射区域，就不会发生甚至在理论上）。除非你拔出插件（或内核崩溃），否则数据将被写入并且一致 数据只能以多个文件系统块写入，因为内存页面是设备块的倍数，文件映射不知道任何其他内容，它只是以这种方式工作。
您可以种类（忽略任何可能的无缓冲磁盘写入缓存）通过write控制磁盘上的内容。当该函数返回时，之前缓冲区中的内容已发送到磁盘
但是，这仍然不能防止您的进程同时在另一个线程中崩溃，并且它不会阻止某人拔出插件。 fdatasync优先于fdatasync，因为它不接触inode附近的任何内容，这意味着它更快更安全（因为长度尚未更新，您可能会丢失后续崩溃中写入的最后一个数据，但你永远不应该破坏/破坏整个文件。）
C库函数（fsync）执行自己的缓冲并控制您编写的数据量，但只有“写入”数据意味着它存储在C库拥有的缓冲区中（在你的过程）。如果进程终止，数据就会消失。无法控制数据如何击中磁盘，或者如果有的话。 （Nb：在fwrite范围内你确实有一些控件，这会立即将缓冲区的内容传递给底层写入函数，最有可能是fflush，然后再返回有了它，你回到了第一段。）
异步IO（内核 aio）将绕过内核缓冲区，通常直接从您的进程中提取数据。您的流程终止，您的数据消失了。 Glibc aio使用阻止writev的线程，与第1段中的相同。
如果您随时拔下插头或点击“关闭”开关会怎样？没人知道。
通常一些数据会丢失，一个操作系统可以提供很多保证，但它不能做到魔术。虽然从理论上讲，您可能有一个系统可以使用电池缓冲RAM，或者系统具有巨大的专用磁盘缓存，该缓存也是电池供电的。没有人能说出来。无论如何，计划丢失数据
也就是说，如果你继续写一个文件，那么曾经写过的东西通常不应该被破坏（尽管如此，真的发生了什么，“不应该”并不意味着很多）。
总而言之，在追加模式或文件映射中使用write应该足够好，无论如何它们都是最好的。除了突然的电力损失，它们是可靠和有效的
如果出现电源故障，UPS将提供比任何软件解决方案都能提供的更好的保证。
至于文件大小，我认为没有任何理由人为地限制文件大小（假设一个合理的新文件系统）。 “标准”Linux文件系统（如果有这样的东西）的常用文件大小限制在TB级范围内。
无论哪种方式，如果您因为出于某种原因破坏一个文件可能会破坏30天的数据而感到不安，那么每天都要开始一次新文件。它不需要额外费用。
答案 1 :(得分：0)
这里的问题是，情景没有准确描述。 因此，一些答案是猜测：
希望这有助于迈出第一步。 如果您决定去哪个方向，请添加信息 问题 - 您提出的要求越多，答案就越好 可以。
答案 2 :(得分：0)
你手头有一个有趣的问题。我不是这方面的专家，但有足够的知识来评论这些。
如果您还没有，可以阅读本文，了解各种文件系统linux的一般概述。缺点，限制等 Comparison of FileSystems in Linux
1）我遇到了自动旋转日志文件库，在Python / Perl中，在C / c ++中也是如此。 2/3/4）日记文件系统可以更大程度地防止文件系统崩溃。他们也支持数据的日志记录，但没有大量使用它。
答案 3 :(得分：0)
你应该使用SQLite。它解决了您需要的一切。如果您正确使用该数据库，请包括速度。