问压缩以提高硬盘写入性能

EN

这取决于许多因素，我认为没有一个正确的答案。归根结底是这样：

如果您有足够的CPU带宽用于此目的，那么您能不能比磁盘的原始写入性能更快地压缩原始数据，乘以您正在达到的压缩比(或您试图获得的速度的倍数)？

考虑到目前10%MBytes/秒的数据写入率相对较高，这是一个相当高的障碍。就其他一些答案而言，您可能需要容易压缩的数据，并且只需用一些合理性类型的测试来对其进行基准测试并找出答案。

相对于特定的意见(猜测！？)关于额外的核心。如果将数据压缩连接起来，并保持核心(S)与文本的高压缩比，那么这种技术很可能会取得一些成果。但这只是猜测。在磁盘写入和压缩操作之间交替的单个线程应用程序中，在我看来，这种可能性要小得多。

是的，是的，绝对的。

可以这样看:以每秒以兆字节为单位的最大连续磁盘写入速度。(去测量它吧，时间太大了，或者什么的。)假设是100 in /s，现在以兆赫为单位计算CPU速度，比如说3Ghz =3000 3Ghz。CPU速度除以磁盘写入速度。这是CPU空闲的周期数，您可以将这些周期用于每字节的压缩。在本例中，3000/100 =每字节30周期。

如果您有一个算法可以将数据压缩25%以获得有效的125‘t/s的写入速度，那么您将有24个字节运行它，并且它基本上是免费的，因为CPU在等待磁盘运转时不会做任何其他事情。每字节24周期=每128字节缓存行3072周期，很容易实现.

在阅读光学媒体时，我们一直在这样做。

如果你有一个空闲的第二个核心，那就更容易了。只要把日志缓冲区交给内核的线程，它就可以花很长的时间来压缩数据，因为它没有做任何其他事情！唯一棘手的一点是，您实际上希望有一个缓冲区环，这样就不会让生产者线程(编写日志的线程)等待使用者线程(将其写入磁盘)所保存的缓冲区的互斥对象。

是的，至少10年来都是如此。有关于它的操作系统文件。我想克里斯·斯莫尔可能已经研究过其中的一些了。

就速度而言，在较低质量级别上的gzip/zlib压缩相当快；如果不够快，您可以尝试 FastLZ。使用额外核心的一种快速方法就是使用popen(3)通过gzip发送输出。