在磁盘I / O期间窗帘后面发生了什么？
当我在文件中寻找某个位置并写入少量数据（20个字节）时，幕后会发生什么？
我的理解
据我所知，可以从磁盘写入或读取的最小数据单元是一个扇区（传统上是512字节，但该标准现在正在改变）。 这意味着写入需要读取整个扇区的20个字节，在内存中修改其中一些并将其写回磁盘。
这是我期望在无缓冲I / O中发生的事情。 我还希望缓冲的I / O做大致相同的事情，但要聪明一点。 所以我会想，如果我通过随机搜索和写入来打破窗口的局部性，缓冲和无缓冲的I / O应该具有相似的性能……也许无缓冲的出现稍微好一些。
然后，我知道缓冲I / O仅缓冲一个扇区是疯狂的，所以我也可能期望它执行得非常糟糕。
我的应用程序
我正在存储由SCADA设备驱动程序收集的值，该驱动程序接收超过十万点的远程遥测。 文件中有额外的数据，每条记录为40个字节，但在更新期间只需要写入20个字节。
预执行基准
为了检查我是否需要想出一些出色的过度设计的解决方案，我已经使用写入文件的几百万随机记录进行了测试，该文件可能包含总共200,000条记录。 每个测试都使用相同的值对随机数发生器进行种子处理。 首先，我擦除文件并将其填充到总长度（大约7.6兆），然后循环几百万次，将随机文件偏移和一些数据传递给两个测试函数之一：
void WriteOldSchool( void *context, long offset, Data *data ) { int fd = (int)context; lseek( fd, offset, SEEK_SET ); write( fd, (void*)data, sizeof(Data) ); } void WriteStandard( void *context, long offset, Data *data ) { FILE *fp = (FILE*)context; fseek( fp, offset, SEEK_SET ); fwrite( (void*)data, sizeof(Data), 1, fp ); fflush(fp); } 也许没有惊喜？
OldSchool方法名列前茅 – 很多。 它的速度提高了6倍（148万，而每秒232000条记录）。 为了确保我没有遇到硬件缓存，我将数据库大小扩展到了2000万条记录（文件大小为763兆字节）并获得了相同的结果。
在你指出对fflush的明显调用之前，让我说删除它没有任何影响。 我想这是因为当我寻找足够远的地方时必须提交缓存，这正是我大部分时间都在做的事情。
发生什么了？
在我看来，每当我尝试写入时，缓冲的I / O必须读取（并且可能全部写入）大块文件。 因为我几乎没有利用它的缓存，这非常浪费。
另外（我不知道磁盘上硬件缓存的细节），如果缓冲I / O在我只改变一个扇区时试图编写一堆扇区，那么会降低硬件缓存的有效性。
是否有任何磁盘专家可以比我的实验结果更好地发表评论和解释？ =）
实际上，至少在我的GNU libc系统上，看起来stdio在写回更改的部分之前正在读取4kB块。 对我来说似乎是假的，但我想有人认为当时这是一个好主意。
我通过写一个简单的C程序来检查打开一个文件，写一小段数据，然后退出; 然后在strace下运行它，看看它实际触发了哪些系统调用。 写入偏移量为10000时，我看到了这些系统调用：
lseek(3, 8192, SEEK_SET) = 8192 read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1808) = 1808 write(3, "hello", 5) = 5
似乎你想要坚持这个项目的低级Unix风格的I / O，嗯？
C标准库函数执行额外的缓冲，通常针对流式读取进行优化，而不是随机IO。 在我的系统上， 我没有观察到Jamey Sharp看到的虚假读取，当偏移量未与页面大小对齐时，我只看到虚假读取 – 可能是C库总是试图将其IO缓冲区保持对齐到4kb或一些东西。
在你的情况下，如果你在一个相当小的数据集中进行大量的随机读写操作，你可能最好使用pread / pwrite来避免不得不寻找系统调用，或者简单地对数据集进行mmap并写入数据集在内存中（如果您的数据集适合内存，则可能是最快的）。