linux - 在Linux中可靠写入

Question

我的要求是向文件系统中写入一个永不结束的传入可变大小二进制消息流。平均大小为2KB的邮件每秒到达1000条。因此，一小时内，消息总数将为3600*1000*2=6.8GB。
这些消息的主要目的如下
一。存档以备审计
2。提供搜索界面
我的问题是
有没有一个开源软件可以解决这个问题
如果进程以块大小的倍数写入，而进程在写入块的过程中崩溃，会发生什么样的错误
如果应用程序已写入块大小，但文件系统尚未将数据刷新到磁盘，则会发生什么类型的错误。
索引节点在任何情况下都会损坏吗
linux中有文件大小限制吗？
有理想的文件大小吗？大文件（GB）和中文件（MB）的优缺点是什么
还有什么要注意的吗？
我的首选是使用C++，但是如果需要，我可以切换到C。

Answer 1

一旦write或writev返回（即操作系统已接受），操作系统就负责将数据写入磁盘。这不再是你的问题了，而且它的发生完全没有考虑到你的流程崩溃。请注意，您无法控制一次接受或实际写入的确切数据量，也无法控制它是否以文件系统块的倍数出现，也无法控制它是否有任何特定的大小。您向write发送一个请求，它告诉您它实际接受了多少，它将根据自己的判断将该请求写入磁盘。
这可能会以块大小的倍数发生，因为这对操作系统来说是有意义的，但这并不能以任何方式得到保证（在许多系统中，包括Linux，读写是通过文件映射实现的，或者与文件映射紧密耦合）。
同样的“不必担心”保证了文件映射的有效性（除了理论上的例外，崩溃的应用程序原则上仍然可以写入到一个仍然映射的区域，但是一旦你取消了一个区域的映射，即使理论上也不可能发生这种情况）。除非拔掉插头（或者内核崩溃），否则数据将被写入并保持一致。
数据只会以文件系统块的倍数写入，因为内存页是设备块的倍数，而文件映射不知道其他任何东西，它就是这样工作的。
您可以（忽略任何可能的无缓冲磁盘写缓存）使用fdatasync来控制磁盘上的内容。当该函数返回时，以前在缓冲区中的内容已发送到磁盘。
但是，这仍然不能防止进程在同一时间崩溃到另一个线程中，也不能防止有人拔出插头。fdatasync比fsync更受欢迎，因为它不接触索引节点附近的任何东西，这意味着它更快、更安全（由于长度尚未更新，您可能会丢失在后续崩溃中写入的最后一个数据，但您永远不应破坏/损坏整个文件）。
C库函数（fwrite）执行它们自己的缓冲，并让您控制您写入的数据量，但是“写入”数据只意味着它存储在C库（在您的进程中）拥有的缓冲区中。如果进程结束，数据就会消失。无法控制数据是如何到达磁盘的，或者如果有。（注意：在您可以fflush的范围内，您确实有一些控件，这将在返回之前立即将缓冲区的内容传递给底层写函数，很可能是writev。说完，你又回到了第一段。）
异步IO（kernel aio）将绕过内核缓冲区，通常直接从进程中提取数据。你的进程结束了，你的数据消失了。Glibc aio使用阻塞write的线程，与第1段中的相同。
如果你随时拔掉插头或按下“关”开关会发生什么？没人知道。
通常一些数据会丢失，一个操作系统可以给很多保证，但它不能起到神奇的作用。尽管在理论上，您可能有一个用电池缓冲RAM的系统，或者有一个用电池供电的巨大专用磁盘缓存的系统。没人知道。无论如何，计划丢失数据。
也就是说，如果你一直在一个文件中追加内容，那么一旦写入的内容通常不会被破坏（尽管，实际上任何事情都可能发生，“不应该”并不意味着什么）。
总之，在追加模式或文件映射中使用write应该已经足够好了，不管怎样，它们都已经足够好了。除了突然断电，它们是可靠和有效的。
如果停电是个问题，UPS将提供比任何软件解决方案都能提供的更好的保证。
至于文件大小，我认为没有任何理由人为地限制文件大小（假设有一个相当新的文件系统）。“标准”Linux文件系统的通常文件大小限制（如果有的话）在TB范围内。
不管怎样，如果你对一个文件因任何原因损坏可能会破坏30天的数据的想法感到不安，那么每天创建一个新文件。不需要额外的费用。